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Chapter  1 
Introduction 


In  this  chapter,  the  underlying  concepts  of  the  Hierarchical  Target  Extrac¬ 
tion,  Recognition  and  Tracking(HiTert)  System  will  be  addressed.  These 
concepts  are  essential  for  understanding  the  rest  of  the  material.  Some  im¬ 
plementation  issues  will  also  be  briefly  discussed. 

1.1  structure  of  the  HiTert  System 

The  HiTert  system  is  aimed  to  study  a  hierarchictd  target  extraction,  recogni¬ 
tion  and  tracking  system  based  on  passive  sensors,  which  could  be  integrated 
with  other  battlefield  resources[l].  The  HiTert  system  consists  of  the  mu¬ 
tually  benefici2j  subsystems  running  different  algorithms  and  executing  in 
parallel  at  several  hierarchical  levels.  Together  these  subsystems  cooperate 
in  seeking  the  solution  for  the  complex  problem  beyond  the  capability  of  einy 
one  of  the  subsystems.  The  HiTert  system  is  composed  of  four  hierarchical 
levels  as  shown  in  Figure  1.1: 

•  Preprocessing  Level:  Imagery  acquiring,  noise  filtering  and  compensa¬ 
tion  of  the  effect  of  the  imaging  system[3]. 
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Figure  1.1:  Structure  of  HiTert  system 


CHAPTER!,  INTRODUCTION 


3 


•  Low  Level:  Target  extraction  and  tracking.  The  tracker  at  this  level 
mainly  uses  primitive  information  such  as  the  target  centroid  position, 
while  the  image  processor  at  this  level  classifies  the  pixels  of  images 
and  separates  the  t2Lrget  from  the  background. 

•  Middle  Level;  Target  recognition  and  tracking.  The  image  processor  at 
this  level  is  responsible  for  yielding  target  orientation  information  and 
object  identification.  These  refined  results  are  utilized  by  the  tracker 
at  this  level.  The  processing  at  this  level  has  a  longer  time  period  than 
that  at  the  low  level  processing. 

•  High  Level:  Command,  Control  amd  Communication.  This  high-level 
reasoning  module  is  responsible  for  the  coordination  of  low-level  subsys¬ 
tems,  information  fusion,  user  interaction,  and  interaction  with  other 
battle  field  resources.  The  blackboard  architecture  allows  the  informa¬ 
tion  sharing,  subsystem  coordination  and  integration  with  other  battle 
field  resources. 

1.2  Scenario  Under  Consideration 

Figure  1.2  shows  the  simple  battle  field  scene  being  considered.  It  consists  of 
a  flat  terrain,  a  moving  tracked  vehicle,  a  house,  a  generic  tree.  Such  a  simple 
scene  still  possesses  the  characteristics  of  a  complicated  battle  field  environ¬ 
ment.  For  instance,  certain  obstacle  avoidance  strategies  will  be  adopted 
by  the  driver  in  the  decision-making  of  the  driving  logic;  overlapping  of  the 
target  and  ground  obstacles  may  pose  ambiguity  problems  for  the  image  pro¬ 
cessor  to  resolve.  However,  such  a  simple  scenario  ameliorates  the  complexity 
of  scene  rendering  and  also  makes  it  more  aunenable  to  study  and  analysis. 

It  should  be  noted  that  to  be  consistent  with  the  Dore  3D  graphics 
system[ll],  which  is  used  to  generate  the  world  view  images,  the  camera 
coordinate  system  is  such  that  the  “camera”  looks  along  the  negative  Zc 
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Figure  1.2:  Tracking  scenario 
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direction  and  Xc^  yc  are  mapped  to  the  horizontaJ  dirction(left  to  right)  and 
vertical  direction(down  to  up)  of  the  screen. 

One  set  of  trajectory  data  is  shown  in  Figure  1.3.  It  is  believed  that 
the  target  may  do  any  maneuvering  as  the  driver  deems  necessary  to  avoid 
the  threat  in  a  real  environment.  A  maneuvering  is  realizable  as  long  as  the 
certain  dynamic  constraints  are  satisfied: 

•  The  acceleration  and  deceleration  can  not  exceed  the  thrust  capability 
as  determined  mainly  by  the  characteristics  of  the  propulsion  system 
and  the  terrain  sustaining  capability. 

•  Under  the  no-skidding  condition,  the  target  lateral  acceleration  should 
not  exceed  the  terrain  sustaining  capability  determined  by  the  lateral 
frictional  coefficient: 

an  =  wv  <  litg 

where  an  is  the  centripetal  acceleration,  u;  the  angular  rate,  v  the  for¬ 
ward  speed,  fit  the  lateral  frictional  coefficient,  g  the  gravitational  con¬ 
stant. 

1.3  Some  Implementation  Issues 

1.3.1  A  Generic  Subsystem 

The  HiTert  system  spans  several  research  fields  such  as  target  dynamics 
modeling  and  tracking,  image  processing,  artificial  intelligence  and  database. 
Many  subproblems  are  being  actively  studied.  The  full  implementation  of 
such  a  hierarchical  system  is  difficult.  And  further  in-depth  study  of  HiTert 
is  needed.  As  a  result,  we  break  down  the  complex  problem  into  simple 
ones,  concentrating  on  building  a  testbed  for  the  subsystem  operating  at 
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ume(sec)  Y(feci) 


Figure  1.3:  Trajectory  data 

different  levels.  From  the  point  of  view  of  information  flow,  a  subsystem 
at  a  certain  level  has  the  information  loop  as  shown  in  Figure  1.4.  Such  a 
testbed  is  simple  enough  to  implement,  yet  still  flexible  enough  for  further 
development.  With  such  a  testbed,  different  modules  or  algorithms  can  be 
plugged  in  with  minimum  efforts.  This  allows  the  easy  comparisons  and 
selections  of  different  adgorithms,  and  it  also  makes  it  possible  to  quickly 
prototype  a  subsystem. 
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Figure  1.4:  A  generic  subsystem 


1.3.2  Non-real  Time  Simulation 

Optical  imaging  system  is  one  of  the  important  components  of  the  HiTert 
system.  Computer  graphics  principles  are  utilized  to  generate  the  images  for 
a  simulated  battle  field  scene.  Real-time  simulation  of  a  battle  field  scene 
is  tempting,  but  requires  special  hardware,  which  is  prohibitively  expensive. 
Also,  segmenting  images  is  very  CPU-intensive  and  special  hardware  is  also 
required  if  the  real-time  response  is  desired.  Because  of  the  unavzdlability  of 
the  special  hardware  due  to  its  prohibitively  high  cost,  it  is  decided  to  perform 
CPU-intensive  work  off-line,  i.e.  a  sequence  of  images  are  pregenerated  and 
presegmented  and  the  results  are  stored  on  disk.  The  raw  images  as  well 
as  segmented  images  are  made  available,  on  demand,  to  the  HiTert  system 
during  its  operation. 

The  basic  idea  behind  this  approach  is  as  follows.  A  fixed  world-view 
“camera”  is  introduced  for  the  purpose  of  generating  a  temporal  sequence 
of  world  images.  This  “camera”  is  assumed  to  have  sufficiently  large  field 
of  view  such  that  the  target  always  moves  within  the  field  of  view  for  the 
time  period  of  interest.  The  tracking  camera,  which  is  the  imagery  acquiring 
system  in  HiTert,  is  able  to  pane  commanded  by  the  tracking  system.  If 
both  the  world-view  camera  and  the  tracking  camera  are  located  at  the  same 
position,  if  the  world-view  camera  has  a  sufficiently  large  field  of  view,  £ind 
if  the  tracking  camera  has  sufficiently  small  panning  angles,  then  the  image 
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Figiire  1.5:  World  and  camera  views 


as  seen  by  the  tr2u:king  camera  is  just  a  subimage  of  the  world-view  image. 
This  is  illustrated  in  Figure  1.5.  ' 

The  presegmentation  is  done  on  a  subimage  that  is  centered  around  the 
target.  Portion  of  this  subimage  may  overlap  with  the  image  of  the  tracking 
camera.  It  should  be  noted  that  if  HiTert  has  a  poor  performance  in  oper¬ 
ation,  the  tracking  camera  may  be  commanded  to  look  at  a  wrong  region. 
In  this  case,  the  presegmented  image  and  the  tracking  camera  image  may 
have  no  overlapping  at  all.  If  HiTert’s  performance  is  very  poor,  the  track¬ 
ing  camera’s  boresight  may  completely  fadl  outside  of  the  viewing  angles  of 
the  world-view  camera.  Conversely,  the  symbiotic  resonance  of  the  track¬ 
ing  system  and  image  processing  system  can  yield  a  tight  lock  on  target  [2]. 
Therefore,  with  this  non-real  time  simulation  approach,  in  which  the  CPU¬ 
intensive  jobs  are  preprocessed  ,  HiTert  system  can  be  implemented  on  a 
general- purpose  digital  computer;  and  reasonably  fast  on-line  responses  can 
be  achieved;  yet  the  dynamic  performance  of  the  HiTert  system  can  still  be 
fully  evaluated. 

The  presegmentation  allows  the  implementation  of  sophisticated  time- 
consuming  image  processing  algorithms.  This  non-real  time  simulation  ap- 
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proach  also  makes  it  possible  to  study  tracking  and  image  processing  algo¬ 
rithms  separately. 

It  should  be  pointed  out  that  the  world-view  “camera”  is  fictitious.  Its 
main  purpose  is  to  generate  the  world-view  image  database. 

1.4  Development  Environment 

1.4.1  Hardware  Architecture 

The  School  of  Aeronautics  and  Astronautics  has  clusters  of  Sun  worksta¬ 
tions  ranging  from  Sun  3/50  to  Sparc  1,  running  vendor-enhanced  UNIX' 
operating  system(SunOS  4.x).  These  workstations  are  p2irt  of  the  nodes  on 
the  Local  Area  Network,  which  is  connected  to  the  Engineering  Computing 
Network(ECN).  ECN  consists  of  varieties  of  platforms,  ranging  from  work¬ 
stations  to  supermini  computers,  connected  via  ethernet. 

The  primary  development  work  is  done  on  a  Sun  workstation,  with  the 
de  facto  industry  standard  X  Window  System^  Version  11,  Release  4.  The 
network  environment  as  well  as  the  network- transparency  of  X  windowing 
system  allows  us  to  explore  the  distributed  processing  in  the  HiTert  system. 
Also  whenever  possible,  more  dedicated  computers  are  used.  For  example, 
the  image  database  is  generated  on  a  Stardent  3000  machine,  a  supermini 
graphics  computer. 

1.4.2  Interprocess  Communication(IPC) 

On  current  UNIX  systems,  processes  can  communicate  with  one  another  via  a 
variety  of  methods,  including  shared  file  pointers,  signals,  files,  pipes,  FIFO’s, 
semaphores,  messages,  shared  memory  and  Berkeley  sockets[6,  7).  Shared 
memory  provides  the  fastest  IPC  mechanism.  However,  the  communicating 

*UNIX  is  a  registered  trademark  of  AT&T  Bell  Laboratories. 

*The  X  Window  System  is  a  trademark  of  MIT. 
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processes  must  physically  reside  on  the  same  machine.  Also,  shared  mem¬ 
ory  makes  the  communication  interface  complicated,  while  software  modules 
are  constantly  evolving.  BSD  socket-based  IPC  mechanism  has  the  same 
drawback  in  communication  interface  design  as  shared  memory,  although  it 
allows  communication  among  the  processes  running  on  different  machines 
on  the  Internet,  To  simplify  the  communication  interface,  files  are  chosen 
as  the  IPC  mechanism  for  the  HiTert  system  at  this  stage.  Files  provides 
IPC  for  the  processes  running  on  the  m2u:hines  with  the  same  Network  File 
System.  Also,  there  are  standard  C  libraries  on  all  systems  supporting  the 
C  language[4,  5],  and  most  people  axe  familiar  with  I/O  on  files.  Another 
important  factor  in  choosing  files  as  the  IPC  mechanism  is  the  availability 
of  the  Xll-based  Cantata  visual  programming  language  coming  with  the 
Khoros  system[8].  Cantata  provides  a  graphical  user  interface  for  the  UNIX 
processes  communicating  via  files,  thus  simplifying  our  work  in  the  graphical 
user  interface  design. 

1.4.3  Cantata  Visual  Programming  Language 

One  of  the  major  components  of  the  Khoros  system  is  its  Cantata  visual 
programming  language.  Cantata  provides  a  graphical  user  interface  for  the 
conventional  command  line  options  interfcice  of  UNIX  programs.  Graphi¬ 
cally  expressed  and  visually  oriented,  Cantata  consists  of  following  graphical 
elements:  a  workspace^  forms^  glyphs^  and  connections.  To  build  a  Can¬ 
tata  application,  the  user  selects  the  desired  programs(or  processing  nodes), 
places  the  corresponding  glyphs  on  the  workspace,  and  then  interconnects 
the  glyphs  from  upstream  to  downstream  to  indicate  the  data  flow  of  pro¬ 
cessing.  The  built-in  control  constructs,  as  well  as  its  expression  parser  and 
dynamic  execution  scheduler  make  Cantata  behaves  like  a  visual  shell.  Be¬ 
cause  of  these  features,  Cantata  is  selected  as  a  visual  presentation  tool  for 
our  UNIX  command  line  interface  programs. 


Chapter  2 

Installation  Guide 


In  this  chapter,  some  highlights  of  the  installation  procedures  vnll  be  pre> 
sented  to  reduce  the  installation  efforts  on  the  user’s  part.  Currently,  all  the 
modules  are  implemented  in  the  C  Language,  though  some  Fortran  and  Lisp 
modules  may  be  included  in  the  future.  Efficiency  and  portability  have  been 
taken  into  account.  All  the  programs  have  been  tested  on  Sun3  and  Sparc 
workstations. 

2.1  Platform  Requirements 

A  Sun  workstation  of  3/60  or  later  model  is  recommended  but  not  mandatory. 
Other  hardware  supporting  C  and  UNIX  environment  is  just  fine,  although 
some  additional  porting  efforts  may  be  needed.  However,  in  order  for  all  the 
modules  to  run,  the  X  window  system( version  11,  release  4)  and  the  Khoros 
system  must  already  be  installed.  We  shall  assume  this  to  be  true  in  the 
following. 

The  HiTert  system  takes  about  10  mega  bytes  of  disk  space  and  need  8 
MB  main  memory  (RAM)  to  achieve  a  reasonable  real-time  response  because 
of  the  large(900  x  900  pixels)  images  involved. 
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2.2  Unpack  the  Source 

To  unpack  the  tar  file  hitert . tar.2,  go  to  the  directory  in  which  the  HiTert 
source  tree  is  to  be  installed.  Note  that  this  directory  does  not  have  to  be  in 
the  Khoros  source  tree.  Then  type 

example^!  zcat  hitert.tar.Z  I  tar  xvf  - 

This  should  result  in  HiTert  source  directory  hitert. 

2.3  Installation  Environment  Variables 

The  environment  variable  HITERTJiOME  must  be  set  to  the  full  path  of  the 
HiTert  source  directory.  For  example,  if  you  are  using  csh-shell,  type 

csh-exampleX  setenv  HITERT.HOME  /home/gus2/luj /hitert 

If  you’re  using  ksh,  bash,  or  sh  shell,  type 

sh-example%  HITERT.H0ME*/home/gus2/luj /hitert 
sh-exajBple%  export  HITERT.HOME 

Note  in  the  the  above  examples,  /home/gus2/luj /hitert  should  be  modified 
to  reflect  the  change  of  the  full  path  name  of  the  HiTert  source  directory. 
From  now  on  we  shall  refer  to  this  directory,  following  a  UNIX  shell’s  syntax, 
by  symbol  $HITERT-HOME. 

To  compile  all  the  progreuns,  you  should  also  have  the  environment  vari¬ 
able  KHOROSJIOME  set  properly  to  the  directory  where  the  Khoros  system  is 
installed.  This  is  necessary  for  linking  with  the  Khoros  libraries  in  compiling 
some  progr2uns.  Section  3.2  has  some  information  on  how  to  set  KHOROS -HOME. 
For  further  information  on  how  to  set  this  environment  variable,  please  con¬ 
sult  Khoros  reference  manual. 
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2.4  Compilation  and  Installation 

After  you  have  unpacked  the  HiTert  source  and  set  the  environment  variables, 
issue  the  following  command  while  in  $HITERTJiOME  directory: 

ezaapleX  ./InstallNe 

InstallNe  is  a  shell  script  intended  to  automate  the  installation  process. 
In  the  case  such  a  global  automated  compiling  procedure  fails,  you  may  want 
to  compile  the  programs  individually.  To  compile  a  program,  you  may  need 
to  modify  the  corresponding  Imakefile^,  and  then  update  Makefile  by  issuing 
commands: 

ezampleX  rm  -f  Makefile 

ezampleX  makemake  #  Khoros  program.  Not  zmkmf 

ezampleX  make  all 

After  the  successful  compilation  of  the  programs,  you  need  to  copy  or 
move  the  resulting  executable  programs  to  a  directory.  This  directory  should 
be  included  in  your  shell’s  search  path  by  modifying  the  environment  vari¬ 
able  PATH  as  necessary.  You  may  also  want  to  install  manuad  pages  to  the 
appropriate  directory  and  modify  the  man(l)’s  environment  variable  MANPATH 
so  that  HiTert ’s  UNIX  manual  page  directory  is  in  man(l)’s  search  path. 


^The  [makefile  is  Khoros- flavored  and  has  the  difference  with  the  [makefile  of  X11R4 
from  MIT. 


Chapter  3 

Getting  Started 

3.1  The  X  Window  System 

It  is  assumed  that  you  have  some  basic  working  experience  in  a  windowing 
environment,  and  that  you  know  how  to  login  a  workstation  with  a  bitmap 
display  and  start  the  X  window  system.  This  procedure  varies  from  the  site 
to  site.  Usually,  there  is  a  site-customized  shell  script  program  available  to 
help  the  user  to  invoke  xinit  (1)  and  a  set  of  applications  such  as  xtermd), 
xclock(l)  and  etc. 

3.2  The  Khoros  System 

It  is  also  assumed  that  now  both  Khoros  and  HiTert  system  have  been  suc¬ 
cessfully  installed  and  you  have  some  exposure  to  cantata(l),  a  visual  lan¬ 
guage  environment  in  Khoros  system.  If  you  know  how  to  start  Khoros 
programs  from  your  home  directory,  you  may  skip  this  section  and  go  to 
Section  3.3. 

To  access  Khoros  programs,  you  need  to  set  the  environment  variable 
KHOROS  JIOME  to  the  full  path  of  the  directory  in  which  Khoros  is  installed(this 
directory  will  be  referred  to  by  the  symbol  SKHOROS  JIOME).  In  $KH0R0S  JIOME, 
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there  should  be  a  file  naimed  .khoros-env  for  csh  users.  You  may  need  to 
add  the  following  lines  in  your  .login  or  .cshrc  file: 

setenv  KHOROS.HOME  /home/gus3/khaos 
source  $KH0R0S.H0NE/ .khoros.env 
set  path  -  ($KH0R0S.H0ME/bin  $path) 

If  you  are  using  other  shells  such  as  ksh,  bash  or  sh,  you  need  to 
modify  $KH0R0S^0N£/ .khoros.env.  In  your  home  directory,  create  a  file 
.khoros.env.sh  which  contains  the  following  lines 

KH0R0S.H0M£*/home/gus3/khaos  #  edit  this  as  necessary 

KHOROS.MAIL-$USER 

KHOROS.LOG-$HOME/khoros.cind .  log 

KH0R0S.VERB0SE«no 

KH0R0S.CACHE_SIZE«4194304 

KHOROS.CACHE-no 

TMPDIR»${TMPDIR-/tmp} 

export  KHOROS.HOME  KHOROS.HAIL  KHGROS.LOG  KHOROS.VERBOSE  \ 
KHOROS.CACHE.SIZE  KHOROS.CACHE  TMPDIR 

Then  in  your  .profile,  add  the  following  statements: 

.  $H0ME/. khoros.env.sh 
PATH-$KHOROS.HOME/bin:$PATH;  export  PATH 

3.3  Environment  Variables  for  the  HiTert 
System 

First,  you  need  to  set  the  shell  environment  variable  HITERT-HOME  to  the 
directory  in  which  the  hitert  source  tree  resides.  For  example,  if  you  are 
using  csh,  just  type  the  following  to  the  shell  prompt: 
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•xaapI^X  setenv  HITERT.HOME  /hoBie/gus2/luj/aro/hitert 

If  you  2ire  a  ksh,  bash,  sh  user,  enter  the  following  at  the  shell  prompt: 

exaiipleX  HITERT.H0ME«/home/gu82/lu j  /aro/hitert 
exaspleX  export  HITERT.HOME 

In  the  above  examples,  /home/gu82/luj /aro/hitert  need  to  be  modi¬ 
fied  reflect  the  changes  to  the  actual  environment.  If  you  want  to  avoid  doing 
this  every  time  after  you  login,  you  may  add  the  corresponding  statements 
to  your  .login  or  .cshrc  file  if  you  are  a  csh  user,  or  to  your  .profile  file 
if  you  are  a  ksh,  bash  or  sh  user. 

You  also  need  to  check  to  see  if  the  shell  environment  variable  PATH 
includes  the  directory  in  which  the  HiTert  programs  are  installed.  If  not,  you 
need  to  modify  PATH  such  that  the  shell’s  search  path  includes  this  directory. 
For  example,  if  the  HiTert  programs  are  installed  in  the  directory  $H0ME/bin, 
you  may  modify  your  shell  PATH  variable  in  the  following  way: 

i  for  C8h  U8er 

setenv  PATH  $H0ME/bin :$PATH 


or 


i  for  k8h,  bash,  sh  user 
PATH»$HOME/bin:$PATH;  export  PATH 

You  may  also  want  to  set  your  environment  variable  MANPATH  so  that 
it  includes  the  directory  in  which  the  manual  pages  for  the  HiTert  system 
are  installed.  For  example,  if  the  manual  pages  for  the  HiTert  system  are 
installed  in  the  directory  $HOME/man/manl,  you  may  set  MANPATH  variable 
this  way: 

#  for  csh  user 

setenv  MANPATH  /usr/man:$HOME/man 
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or 


#  for  ksh,  bash«  sh  user 
MANPATH»/u8r/maii:$H0ME/«an;  export  MANPATH 

To  see  if  you  have  correctly  set  the  environment  variables  for  the  HiTert 
system,  just  type 

ezampleX  hitert  -help 

If  you  are  able  to  see  the  help  message  from  hitert,  congratulations.  If  your 
shell  is  unable  to  find  the  executable  program  hitert,  you  need  to  check  if 
PATH  indeed  includes  the  directory  in  which  the  HiTert  executable  programs 
reside.  If  hitert  reports  an  error,  you  need  to  make  changes  accordingly. 

Similarly,  if  MANPATH  has  been  set  correctly,  you  should  be  able  to  see 
the  on-line  manual  pages  following  this  example: 

ezampleX  man  hitert 

3.4  Command  Line  Interface 

The  HiTert  programs  can  be  invoked  as  an  individual  program  by  typing 
the  command  or  program  name  with  command  line  options.  For  exam¬ 
ple,  if  the  file  prediction.dat  contains  prediction  data  from  the  q-/?-7 
tracker /predictor,  and  if  the  file  exact.dat  contains  the  reference  exact  data 
for  the  target  {>06itions,  you  can  invoke  errAnaly  to  the  perform  error  anal¬ 
ysis  by  typing: 

•zampleX  errAnaly  -pred  prediction.dat  -exact  exact.dat  \ 
-shoeDart  0  -outSpec  spec  -outErr  error.dat 
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errAnaly  will  compute  the  errors  in  each  inertial  x,  y,  2:  component, 
and  store  the  error  data  in  the  file  error.dat.  File  spec  will  contain  the 
statistics  about  the  errors. 

This  is  the  conventional  way  to  invoke  a  UNIX  program,  familiar  to 
most  UNIX  users.  In  this  approach,  a  shell  is  acting  as  the  interface  be- 
tween  the  user  and  the  kernel^  even  though  you  may  not  be  aware  of  this. 
Except  for  xhitert,  all  ether  HiTert  prograuns  can  be  executed  by  using  the 
command  line  interface  from  any  terminal  without  getting  into  X  windowing 
environment. 

If  you  want  to  get  some  simple  help  from  a  program,  just  type 


example^  errAnaly  -help 

This  yields 

Usage:  errAnaly 

-pred  <predfile> 
-exact  <exactfile> 
[-tbf  <tbf>] 

[-tburst  <tburs>] 
[-showDart  <1  or  0>] 
-outSpec  <filenaae> 
[-outErr  <filenaffie>] 
[-help] 


—  data  file  from  the  predictor 

—  exact  data  file  for  comparison. 

—  track-before-fire  time. 

—  burst  interval. 

—  computes  the  dartboard  errors . 

—  output  spec  filename. 

—  prediction  err  data  filename. 

—  print  out  this  help  message. 


If  your  manual  pages  are  properly  installed  and  the  environment  variable 
MANPATH  is  set  properly,  you  may  get  a  more  det2iiled  description  by  using 
UNIX  man(l)  command.  For  example. 


example^  man  errAnaly 
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UNIX  stdin(standard  input)  can  be  used  for  any  one  input  file  by  spec¬ 
ifying  for  the  file  name.  Similarly,  stdout (standard  output)  can  be  used 
for  any  one  output  file  by  specifying  for  the  file  name.  As  a  result,  the 
output  of  one  program  can  be  piped  to  the  input  of  another  program.  For 
example, 

eiampleX  predict  -i  tracker.dat  -o  -  -tp  2  I  errAnaly  -pred  -  \ 
-exact  exact.dat  -showDart  0  -outSpec  spec  -outErr  error.dat 

invokes  the  predict,  which  performs  prediction  based  on  the  tracker  out- 
put(state  estimates)  tracker.dat.  The  prediction  results  are  piped,  as  the 
input,  to  the  program  errAnaly,  which  does  the  error  analysis. 

Experienced  users  may  notice  that  there  are  some  differences  in  the  han¬ 
dling  of  command  line  options  between  the  HiTert  programs  and  Khoros  pro¬ 
grams.  In  the  HiTert  programs,  the  Khoros  program  ghostwriter  has  not 
been  used  to  generate  the  code  for  handling  command  line  options;  instead 
a  much  more  efficient  scheme  is  utilized  to  parse  the  command  line  options. 
Standard  Khoros  flags  ^[-U]  [-P]  [-A  [file]]  [-a  [file]]”  are  not  supported  by  the 
HiTert  programs,  since  we  ourselves  found  little  use  of  them. 

3.5  Cantata  Visual  Language  Interface 

To  access  cantata  visual  language  interface  for  the  HiTert  system,  you  need 
first  start  up  the  X  window  system  from  your  workstation.  Then  from  an 
xterm(l)(an  X-based  terminal  emulator)  type 

wxanpleX  hitert 

This  should  bring  up  the  cantata  visual  language  interface  with  the  cus¬ 
tomized  forms  for  the  HiTert  system.  All  the  HiTert  programs  can  be  ac¬ 
cessed  from  the  pull-down  menu  “HiTERT”  on  the  master  form.  On-line 
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documentation  for  the  corresponding  programs  can  be  invoked  by  pressing 
the  “Help”  button  on  the  pane. 

Within  the  the  cantata  visual  language  environment,  accessing  the  HiTert 
programs  is  the  same  as  accessing  other  Khoros  programs.  You  should  have 
little  problem  in  using  HiTert  programs  if  you  are  familiar  with  cantata. 
Please  consult  Khoros  tutorial  or  reference  manual  for  the  assistance  in  us¬ 
ing  cantata. 

Novice  users  may  find  it  helpful  to  use  hitert2.  This  program  brings  up 
the  cantata  visual  language  interface  as  well  as  a  preassembled  and  stored 
workspace  as  shown  in  Figure  4.1.  This  should  serve  as  a  good  example 
cu3  how  to  assemble  individual  HiTert  programs  together  to  perform  a  team 
work.  It  should  also  serve  as  an  extensible  foundation  upon  which  a  user  can 
configure  HiTert ’s  behavior  by  modifying  parameters. 


Chapter  4 
User’s  Guide 


The  modules  in  HiTert  System  will  be  explained  in  the  following  sectious. 
Chapter  5  is  dedicated  to  the  discussion  on  the  generation  of  the  image 
database.  Interested  reader  may  read  that  chapter  before  this  one. 

4.1  Overview  of  the  Software  Modules 

Figure  4.1  shows  the  primary  modules  comprising  a  generic  subsystem  in 
HiTert:  dataControl ,  w.camera,  Lcamera,  ipc^  tracker^  predictor^  errAnaly 
and  xhitert.  dataControl  module  controls  stairting  and  terminating  time,  and 
etc.  for  the  HiTert  system,  w.camera  is  the  world-view  camera,  responsible 
for  retrieving  the  world-view  images.  Lcamera  simulates  the  servomecha¬ 
nism  for  the  tracking  camera,  receiving  command  signals  from  the  tracker 
and  pointing  the  tracking  camera  to  the  appropriate  direction,  ipc  is  the 
centroid  image  processor,  responsible  for  retrieving  presegmented  images. 
tracker  does  the  state  estimation,  predictor  does  the  prediction  based  on  the 
state  estimation  results  from  the  tracker.  errAnaly  performs  the  error  anal¬ 
ysis  for  the  overall  tracking  system,  xhitert  is  the  instrumentation  module, 
responsible  for  the  displaying  the  world-view  image,  tracking  camera  image, 
segmented  image,  prediction  results,  error  analysis  results,  and  etc. 
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Figure  4.1:  Software  modules  and  data  flows 
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There  are  two  functional  modes  for  the  HiTert  system:  the  batch  mode 
and  loop  mode.  In  the  batch  mode^  each  module  operates  on  all  the  data  for 
the  whole  time  history  of  the  interest  and  outputs  all  relevant  data,  and  then 
it  stops  execution^  Whereas  in  the  loop  mode^  each  module  operates  on  the 
data  one  time  step  at  a  time  and  will  resume  the  execution  when  next  data 
frame  is  available. 

Right  now  the  HiTert  system  only  functions  in  the  batch  mode.  This 
is  done  primarily  because  files  have  been  chosen  as  the  IPC  mechanism  to 
fit  into  the  cantata  visual  environment.  Using  intermediate  files  as  the  IPC 
mechanism  is  most  suitable  for  the  processes  communicating  and  executing 
in  serial  or  in  batch  mode.  It  is  possible  to  implement  the  loop  mode  on 
top  of  cant  at  a.  However,  additional  mechanisms  such  as  file  locking  tech¬ 
niques  must  be  introduced  to  synchronize  and  safeguard  the  communication 
of  processes  executing  in  loop.  Also  in  the  loop  mode,  each  time  interme¬ 
diate  temporary  communication  files  need  to  be  recreated  and  each  module 
need  to  be  restarted  by  caintata  through  fork(2).  This  would  incur  much 
overhead^.  Another  hindrance  for  implementing  the  loop  mode  is  that  more 
powerful  computer  hardware^  is  needed  for  displaying  images  in  succession. 

It  should  be  pointed  out  that  in  order  to  avoid  creating  or  passing  multi¬ 
ple  intermediate  data  files,  spec  files  are  used  frequently  in  the  HiTert  system. 
The  spec  files  are  introduced  as  the  information  corners.  Such  a  spec  file 
differs  from  the  ordinary  data  file  in  that  the  main  purpose  of  the  spec  file  is 
to  bundle  all  the  necessar;*  pointers  to  other  data  files  together  in  a  single  file, 
while  all  other  data  files  retain  their  own  formats  and  integrity.  For  example, 

^In  bcich  mode,  v.caa^ra  only  retrieves  one  frame  from  the  image  database,  and 
zhltart  only  display  one  frame  of  image  to  save  the  time  and  computer  resources.  This 
is  important  particularly  for  the  monochrome  display  for  which  xhitart  has  to  do  CPU¬ 
intensive  dithering  to  the  the  color  image. 

’More  appropriate  IPC  mechanism  for  the  hop  mode  is  to  use  BSD  sockets,  which 
however  is  not  supported  by  cantata  visual  language  environment. 

’For  example,  a  Spare-station  with  16  MB  RAM  and  8-bit  color  display  is  required. 
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tf.canera  creates  a  world  view  image  spec  file.  This  file  contains  the  sequence 
number  of  the  originad  input  image  and  the  path  of  the  world-view  image.  By 
cu:cessing  this  spec  file,  other  processes  can  not  only  access  the  image  data 
by  opening  the  file  with  the  specified  path  but  ^dso  know  the  corresponding 
time  by  appropriately  interpreting  the  sequence  number  in  the  spec  file. 

When  multiple  data  files  need  to  be  accessed  by  the  communicating 
processes,  using  the  spec  file  is  particularly  convenient,  since  the  spec  file 
encapsulates  all  the  information  together  as  a  single  file.  Introducing  spec 
files  not  only  greatly  simplifies  and  cleans  up  the  communication  interface 
design,  but  also  have  the  potential  to  greatly  reduce  the  communication 
overhead,  since  now  multiple  processes  can  access  the  same  data  files  without 
having  to  actually  pass  large  data  files  around. 

4.2  Data  Control  Module 

4.2.1  Introduction 

In  the  batch  mode^  each  HiTert  program  operates  on  all  the  data  contained 
in  the  input  file(s).  Very  often,  however,  one  wants  the  HiTert  system  to  run 
over  a  contiguous  portion  of  the  data  in  the  file.  In  order  to  avoid  the  unnec¬ 
essary  complexity  of  other  HiTert  programs,  dataControl  is  introduced  as  a 
stand-alone  data  control  module  to  isolate  the  problem.  dataControl  is  re¬ 
sponsible  for  selecting  a  portion  of  time  history  over  which  the  HiTert  system 
operates.  It  takes  the  description  file  for  the  world-view  and  segmented  im¬ 
age  database  as  input,  and  outputs  the  selected  segment  description  files  and 
the  corresponding  exact  trajectory  data  file.  It  also  outputs  a  spec  file  which 
contains  the  sequence  numbers  and  the  data  records  from  the  description 
files  at  the  starting  and  terminating  time.  This  way,  each  HiTert  program 
still  operates  on  all  the  data  contained  in  the  input  file(s),  yet  the  HiTert 
system  is  able  to  operate  only  over  the  specified  time  period  as  controlled  by 
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dataControl. 

4.2.2  Command  Line  Options 

Synopsis 

dataControl  -iaginfo  imgInfoFxle  -saginfo  segInfoFile  -tO  start-time  -ta 
end-time  -oiaglnfo  out-imgInfoFile  -oseginfo  out-segInfoFile  -traj  out- 
exact-traj  -spac  out-spec  [-help] 

Options 

-iaglnfo  imgInfoFile  Required  argument.  imglnfoFile  is  the  description 
file  for  the  world-view  image  database  of  the  whole  time  history.  This 
file  consists  of  the  data  records,  with  each  data  record  containing  items 
(see  Section  5.5.3): 

a  time  at  which  the  image  is  to  be  generated.  This  is  identified  by 
a  “  keyword— value"^  pair,  with  the  keyword  being  time. 

a  the  image  identifier  which  maps  to  the  corresponding  image  file. 

This  is  identified  by  a  “  keyword=value'^  pair,  with  the  keyword 
being  image. 

a  the  image  width  in  number  of  pixels.  This  is  identified  by  a  “ 
keyword^^value”  pair,  with  the  keyword  being  width. 

a  the  image  height  in  number  of  pixels.  This  is  identified  by  a  “ 
keyword=value”  pair,  with  the  keyword  being  height. 

a  the  tankas  state  at  that  instant  which  includes 

f  yi  yi  z'l  R  S  T  Ft  S  f 

a  the  camera’s  state  which  includes 

^cl  yd  ^d  Rc  Sc  Tc  Rc  Sc  Tc 


xd  yd  ^d 
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fov  fov  hither  yon  yon 

where  ycI^  ^c/i  Vd^  2ci  denote  the  position  and  velocity 
components  of  the  camera  at  the  instant  in  global  inertial  co¬ 
ordinate  system.  Rc,  Tc^  /2c,  5c,  Tc  refer  to  the  yaw,  pitch 
,  roll  angles  and  their  rates,  fov  and  fov  refer  to  the  field  of 
view(in  degrees)  and  its  time  rate  of  change(in  degrees  per  sec¬ 
ond),  respectively;  hither^  hither  denote  the  position  of  the  front 
clipping  plane  and  its  rate  in  the  camera  coordinate  system;  yon, 
yon  position  of  the  back  clipping  plane  and  its  rate  in  the  camera 
coordinate  system.  The  camera  coordinate  system  is  such  that  its 
initial  orientation  aligns  with  the  inertial  coordinate  system,  and 
the  camera  is  always  looking  towards  the  negative  z  direction  of 
the  body-fixed  right-handed  coordinate  system. 

•  range  of  the  target  to  camera  and  range  rate. 

-seginf  o  stgInfoFile  Required  argument.  segInfoFile  is  the  description  file 
for  the  segmented  image  database  of  the  whole  time  history.  The  file 
is  composed  of  the  data  records  of  the  following  form: 

t ime«2  image«s 1 . seg0020 

8eg.ulx*90  seg.uly»316  seg,width*256  seg_height«256 
tcx«221.809  tcy«444.128  tvx»46.5792  tvy»5. 43854 
out.ulx»-l  out_uly»-l  out.width«256  out.height*256 
8ize*46.8957  scale»2  mag«5. 45893  proj»2 
roll»0  pitch*0  yaw»1.5609 
e8troll«0  estpitch«0  estyaw»l .5708 

-to  start-time  Required  argument,  start-time  specifies  the  time  at  which 
the  tracking  system  should  start  to  run.  This  floating  number  has  the 
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unit  of  seconds. 

Example:  -tO  10 

~tm  end-time  Required  ^irgument.  end-time  specifies  the  time  at  which  the 
tracking  system  should  terminate.  This  floating  number  has  the  unit 
of  seconds.  By  specifying  start-time  and  end-time,,  one  can  ask  system 
to  run  over  the  selected  segment  of  the  trajectory  of  interest  instead  of 
the  whole  time  history. 

Example:  -te  50 

-oimginfo  out-imgInfoFile  Required  argument,  out-img  Info  File  is  the  se¬ 
lected  segment  of  the  description  file  for  the  world-view  image  database. 
It  has  the  same  format  as  the  input  file  imgInfoFile. 

-oseginfo  out-segInfoFUe  Required  argument.  out-segInfoFile  is  the  se¬ 
lected  segment  of  the  description  file  for  the  segmented  image  database. 
It  has  the  same  format  as  the  input  file  segInfoFile. 

-traj  out- exact- traj  Required  argument,  out- exact- traj  is  the  file  contain¬ 
ing  the  selected  segment  of  exact  trajectory.  This  file  has  the  following 
format: 

t  x{t)  y(t)  z(t) 

where  t  is  the  current  time,  r(t),  y{t)  and  z{t)  the  exact  target  position 
coordinates  at  t.  These  floating  numbers  t,  z(t),  y{t)  and  z{t)  have  the 
following  units,  respectively: 

seconds  meters  meters  meters 

-spec  out-spec  Required  argument,  out-spec  is  the  output  spec  file  contain¬ 
ing  information  corresponding  to  the  starting  and  terminating  points. 
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Each  of  the  two  data  records  in  the  file  out-spec  consists  of  the  fol¬ 
lowing  items  in  order:  A  sequence  number,  a  data  record  from  the 
image  description  file  at  3tart-time{or  end-time),  a  data  record  from 
the  description  file  for  the  segmented  image  database  at  start-time(or 
end-time). 

-help  OptionaJ  argument.  When  this  argument  is  specified,  dataControl 
prints  out  a  brief  help  message  and  exits  gracefully. 

4.2.3  I/O  File  Specification 

-imginfo  imgInfoFile 

The  input  image  the  description  file  imgInfoFile  consists  of  the  data  records, 

with  each  data  record  containing  items  (see  Section  5.5.3): 

•  time  at  which  the  image  is  to  be  generated.  This  is  identified  by  a  “ 
keyword=value'^  pair,  with  the  keyword  being  time. 

•  the  image  identifier  which  maps  to  the  corresponding  image  file.  This  is 
identified  by  a  “  keyword=value'^  pair,  with  the  keyword  being  image. 

•  the  image  width  in  number  of  pixels.  This  is  identified  by  a  “  key- 
word=value^  pair,  with  the  keyword  being  width. 

«  the  image  height  in  number  of  pixels.  This  is  identified  by  a  “  key- 
word=value”  pair,  with  the  keyword  being  height. 

•  the  tank’s  state  at  that  instant  which  includes 

f  Xf  yi  zi  X/  yj  Zf  R  S  T  R  S  f 

•  the  camera’s  state  which  includes 
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^cl  Vcl  ^cl  ^cl  Vcl  ^cl  T'c  'I'c 

fov  fov  hither  yon  yon 


where  Xc/,  2/c/>  ^ch  VcU  denote  the  position  and  velocity  compo¬ 
nents  of  the  camera  at  the  instant  in  globed  inertial  coordinate  system. 

Rc,  Scy  Tcy  Rcy  Scy  tc  tcfer  to  the  yaw,  pitch  ,  roll  angles  and  their  rates. 
fov  and  fov  refer  to  the  field  of  view(in  degrees)  and  its  time  rate  of 
change(in  degrees  per  second),  respectively;  hither^  hither  denote  the 
position  of  the  front  clipping  plane  and  its  rate  in  the  camera  coordi¬ 
nate  system;  yon^ybn  position  of  the  back  clipping  plane  and  its  rate  in 
the  camera  coordinate  system.  The  camera  coordinate  system  is  such 
that  its  initial  orientation  aligns  with  the  inertial  coordinate  system, 
and  the  camera  is  always  looking  towards  the  negative  z  direction  of 
the  body-fixed  right-handed  coordinate  system. 

•  range  of  the  target  to  camera  and  range  rate. 

The  data  records  are  separated  by  one  or  more  white  space  charac- 
iers(blanks,  tabs,  newlines).  The  data  items  in  each  data  record  are  also 
separated  by  one  or  more  white  space  characters. 

A  Typical  abridged  imgInfoFile  having  two  data  records  may  look  as 
follows: 

time=2 .000000  image=sl .  iing0020  width*900  height =900 

2000.100000  -79.946000  -1.400000  0.109320  11.046000  0.000000 
1.560900  0.000000  0.000000  0.005000  0.000000  0.000000 
0.000000  0.000000  -5.000000  0.000000  0.000000  0.000000 
0.000000  -0.002778  0.000000  0.000000  0.000000  0.000000 
9.000000  0.000000  -1.000000  0.000000  -2500.000000  0.000000 
2001.703368  -0.331933 
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tiBe*2 . 100000  iBage«8l .  ifflg0021  vidth«900  ]ieight»900 

2000.200000  -78.837000  -1.400000  0.109860  11.141000  0.000000 
1.560900  0.000000  0.000000  0.035000  0.000000  0.000000 
0.000000  0.000000  -5.000000  0.000000  0.000000  0.000000 
0.000000  -0.002778  0.000000  0.000000  0.000000  0.000000 
9.000000  0.000000  -1.000000  0.000000  -2500.000000  0.000000 
2001.759304  -0,329001 

-seginfo  segInfoFile  ^ 

The  input  file  segInfoFile  contains  a  brief  description  of  the  parameters  ac¬ 
tive  at  the  time  each  image  is  segmented.  Each  segmented  image  has  an 
associated  record  of  the  form: 

t ime«0 . 5  imagers 1 . segOOOS 

seg.ulx«40  seg^uly*40  sGg_width*256  seg.height»256 

tcx«130.0  tcy«130.0  tvx*60.0  tvy*80.0 

out.ulx*4  out_uly«4  out.¥idth»256  out.height»256 

size*100  8cale*2.0  mag*2.56  proj*5 

roll*0  pitch»0  yaw«1.5609 

estroll»0  estpitch»0  estyaw*! .5708 

The  information  in  this  file  pertains  strictly  to  the  segmented  image.  Infor¬ 
mation  regarding  the  pre-segmentation  image,  for  example  its  dimensions,  is 
not  recorded  in  this  file;  instead  it  is  in  “si. info”. 

Each  segmented  image  has  a  sequence  number  formed  from  the  last  4 
characters  of  its  name;  time  is  this  sequence  number  divided  by  10. 

The  entire  input  image  is  not  segmented;  only  pixels  falling  in  a  segmen¬ 
tation  window,  measuring  seg.height  by  seg.width,  centered  at  the  last 
estimated  position  of  the  target  are  considered.  The  upper  left  hand  corner 


^  By  Craig  Codrington 
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ci  this  window  is  situated  at  pixel  coordinates  (seg-ulx,seg-uly)  of  the  in¬ 
put  image.  The  new  target  position,  relative  to  the  input  image,  is  taken  to 
be  the  centroid  (tcx,tcy)  of  the  pixels  classified  as  target,  and  an  indication 
of  its  size  is  given  by  the  variances  tvx  and  tvy  of  these  pixels  in  the  x  and 
y  directions,  respectively.  In  fact, 

size  =  (4.1) 

The  segmentation  is  mapped  to  an  output  window,  measuring  out-height 
by  out-width,  and  centered  at  the  new  position  of  the  target  in  the  seg¬ 
mentation  window.  The  upper  left  hand  comer  of  this  window  is  situated 
at  pixel  coordinates  (out-ulx,out-uly)  of  the  input  image.  The  contents  of 
the  output  window  are  what  is  written  to  the  segmented  image  file  image. 

This  is  not  the  whole  story,  however,  for  there  are  5  possible  ways  to  map 
the  segmentation  window  to  the  output  window.  The  particular  mapping 
chosen  is  given  by  proj.  Some  of  these  mappings  (one  to  many,  many  to 
one,  and  fuzzy  many  to  one)  attempt  to  scale  the  target  to  a  consistent  size 
in  the  output  window.  For  these  mappings,  the  scale  gives  the  fraction  of 
the  output  window  that  corresponds  to  one  size  unit  in  the  segmentation 
window.  For  such  mappings,  the  output  window  is  virtual  -  it  does  not 
correspond  to  any  particular  location  in  the  input  image,  so  out.ulx  and 
out-uly  are  both  set  to  -1.  For  scaled  mappings,  the  magnification  mag  is 
defined  as 

out-height->-out-width  ^  g^^le 
2  *  size 

For  other  mappings,  mag  is  set  to  1.  A  brief  description  of  each  mapping  is 
given  below. 

one  to  one  (proj  =  1)  :  The  dimensions  of  the  segmentation  and  output 
windows  are  ignored;  the  entire  input  image  is  segmented  and  the  com¬ 
plete  segmentation  is  written  to  image. 
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one  to  many  (proj  =  2)  :  For  each  pixel  0  io  the  output  window,  find 
the  pixel  S  in  the  segmentation  window  which  is  mapped  to  it,  taking 
account  of  scale  and  size,  and  set  the  class  of  0  to  the  class  of  S. 

many  to  one  (proj  =  3)  :  Initialize  all  pixels  in  the  output  window  to  non¬ 
target.  For  each  target  pixel  S  in  the  segmentation  window,  find  the 
pixel  0  it  is  mapped  to  in  the  output  window,  taking  account  of  scale 
and  size,  and  set  0  to  target. 

fuzzy  many  to  one  (proj  =  4)  :  This  mapping  is  like  the  previous  one 
except  that  all  segmentation  window  pixels  are  mapped  to  the  output 
window;  the  class  of  an  output  window  pixel  is  then  the  class  of  the 
segmentation  window  pixel  mapped  to  it.  If  more  than  one  segmenta¬ 
tion  window  pixel  is  mapped  to  a  single  output  window  pixel  0,  the 
class  to  which  the  largest  number  of  such  segmentation  window  pixels 
belong  becomes  the  class  of  0. 

orthogonal  (proj  =  5)  :  For  each  pixel  0  in  the  output  window,  find  the 
pixel  S  in  the  segmentation  window  which  is  mapped  to  it,  without 
scaling,  and  set  the  class  of  O  to  the  class  of  S. 

The  fields  roll,  pitch,  and  yaw  give  the  target’s  true  orientation,  as 
indicated  in  “si. info”,  while  estroll,  estpitch,  aind  estyaw  give  it’s  esti¬ 
mated  orientation,  derived  from  it’s  computed  moments  by  indexing  into 
“momentfile”  using  a  nearest  neighbor  strategy. 

-oimginfo  out-img  Info  File 

out-img  Info  File  has  the  same  data  format  as  seglnfoFilt. 

-oseginfo  out-seg  Info  File 

out-segInfoFile  has  the  same  data  format  as  segInfoFile. 
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-traj  ouUtxacUiTQj 

The  data  records  making  up  oui-ezact-traj  are  separated  by  one  or  more 
mixed  white  space  characters.  Within  each  data  record,  there  are  three  float¬ 
ing  numbers  t,  x(i),  y(^)  and  z{t)  which  are  also  separated  by  one  or  more 
mixed  white  space  characters,  t  is  the  current  time  and  has  the  unit  of  sec¬ 
onds;  x(^),  y{t)  cLnd  z(t)  the  exact  target  position  coordinates  at  t,  and  each 
have  the  unit  of  meters. 

A  typical  exactfile  having  5  data  records  may  look  as  follows: 

2.000000  2000.100000  -79.946000  -1.400000 
2.100000  2000.200000  -78.837000  -1.400000 
2.200000  2000.200000  -77.718000  -1.400000 
2.300000  2000.200000  -76.590000  -1.400000 
2.400000  2000.200000  -75.453000  -1.400000 

out- exact- traj  is  an  output  file  from  dataControl  and  has  the  same  for¬ 
mat  as  the  input  file  exact-traj. 

-spec  out-spec 

out-spec  is  the  output  spec  file  containing  information  corresponding  to  the 
starting  and  terminating  points.  Each  of  the  two  data  records  in  the  file 
out-spec  consists  of  the  following  items  in  order:  A  sequence  number,  a  data 
record  from  the  image  description  file  at  sfarf-/ime(or  end-time),  a  data 
record  from  the  description  file  for  the  segmented  image  database  at  start- 
fimc(or  end-time).  All  data  fields  are  separated  by  one  or  more  mixed  white 
space  characters.  A  typical  output  spec  file  out-spec  may  look  ais  follows: 

0 

time*0 . 000000  imagers  1 . imgOOOO  width*900  height»900 

2000.000000  -100.000000  -1.400000  0.000000  8.938900  0.000000 
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1.570800  0.000000  0.000000  -0.645000  0.000000  0.000000 
0.000000  0.000000  -5.000000  0.000000  0.000000  0.000000 
0.000000  -0.002778  0.000000  0.000000  0.000000  0.000000 
9.000000  0.000000  -1.000000  0.000000  -2500.000000  0.000000 
2002.504682  -0.446386 
tine*  0.000000  image*  sl.segOOOO 

seg.ulx*  0  seg.uly*  0  seg.width*  256  seg.height*  256 
tcx*  164.716000  tcy*  444.135000  tvx*  45.836500  tvy*  5.356840 
out.ulx*  -1  out.uly*  -1  out. width*  256  out .height*  256 
size*  46.148500  scale*  2.000000  mag*  5.547310  proj*  2 
roll*  0.000000  pitch*  0.000000  yaw*  1.570800 
estroll*  0.000000  estpitch*  0.000000  estyaw*  1.570800 
500 

time*50 .000000  image*sl . img0500  vidth*900  height*900 

1687.500000  -90.137000  -1.400000  -13.408000  -0.067162  0.000000 
3.146600  0.000000  0.000000  -0.200000  0.000000  0.000000 
0.000000  0.000000  -5.000000  0.000000  0.000000  0.000000 
0.000000  -0.002778  0.000000  0.000000  0.000000  0.000000 
9.000000  0.000000  -1.000000  0.000000  -2500.000000  0.000000 
1689.912994  -13.385272 
time*  50.000000  image*  sl.segOSOO 

seg.ulx*  16  seg.uly*  318  seg.width*  256  seg.height*  256 
tcx*  144.383000  tcy*  446.439000  tvx*  13.450800  tvy*  6.849180 
out.ulx*  -1  out.uly*  -1  out.width*  256  out.height*  256 
size*  15.094200  scale*  2.000000  meig*  16.960100  proj*  2 
roll*  0.000000  pitch*  0.000000  yaw*  3.146600 
estroll*  0.000000  estpitch*  0.000000  estyaw*  3.154900 
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4.3  World-view  Camera 

4.3.1  Int  roduct  ion 

W-camera  is  the  program  for  the  world-view  camera  module.  It  is  responsible 
for  retrieving  an  image  based  on  the  user  specifications  on  the  directory  and 
the  format  of  a  file  name  string.  It  uncompresses  the  image  file  as  required 
by  the  user.  It  should  be  pointed  out  that  writing  large  uncompressed  images 
files( approximately  I  MB  per  world-view  image)  incurs  a  great  deal  of  disk 
I/O  overhead.  Because  of  this,  Khoros  routine  readimage()  for  reading  viff 
image  has  been  extended  so  that  the  extended  routine  can  automatically 
uncompress  the  image  in  cache  memory  and  pipe  the  uncompressed  data  to 
image  reading  process.  This  extended  routine  is  employed  by  other  programs, 
which  makes  image  uncompressing  unnecessary. 

Very  often  a  set  of  related  data  files  are  stored  in  the  same  directory. 
Besides  sharing  the  same  directory,  these  files  have  common  prefix^  varying 
index  or  sequence  numbers  and  common  suffix.  In  other  words,  the  paths  of 
the  files  have  the  following  format: 

directory /PrefixSequence-numberSuffix 

No  ^lssumption  has  been  made  as  to  how  the  prefix,  sequence  and  suffix 
are  separated.  If  they  are  indeed  separated  by  some  character  such  as  or 

the  characters  must  be  explicitly  specified  either  in  the  prefix  or  suffix 
part.  Take  my-img-011  .Z  for  example.  The  prefix  is  my-img-,  the  sequence 
number  11,  the  suffix  .Z 

v.caBora  is  ideal  for  retrieving  a  set  of  related  files:  all  the  desired  target 
input  files  must  have  the  same  prefix  and  suffix(if  any)  in  addition  to  having 
same  directory.  Only  the  sequence  or  index  numbers  are  allowed  to  vary. 
The  sequence  or  index  number  comes  from  the  input  spec  file,  which  is  the 
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output  spec  file  of  the  dataControl  module. 

4.3.2  Command  Line  Options 

Synopsis 

v.canera  [-dir  directory']  [-prefix  prefix]  [-nua_width  num-width]  [-suffix 
suffix]  -inSpec  inSpec  -out Spec  outSpec  [-img  imgfile]  [-uc  <1  or  0>] 

[-help] 

Options 

-dir  directory  Optional  argument,  directory  specifies  the  directory  in  which 
a  desired  input  file  resides. 

Default:  the  current  directory. 

Example:  -dir  $HITERTJ10ME/dat a/ images 

-prefix  prefix  Optional  argument.  It  specifies  the  string  that  precedes  the 
sequence  or  index  number  in  a  file  name. 

Default:  null 

Example:  -prefix  si. img 

-num.width  num-width  Optional  argument,  num-width  specifies  the  width 
that  the  numeric  sequence  number  takes.  If  num-width  is  greater  than 
the  number  of  the  digits  that  sequence-number^  has,  sequence-number 
will  be  prepended  with  O’s(zeros)  in  formating  the  file  name  string.  For 
example, 

exampleX  w.camera  -inSpec  inSpec  -outSpec  outSpec  -num.width  4 


^specified  via  -inSpac  inSpcc 
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If  sequence-number  is  123,  v^caaera  will  try  to  find  the  file  with  the 
name  0123  in  the  current  working  directory.  If  num-xvidth  is  less  than 
the  number  of  the  digits  that  sequence-number  has,  num-vndth  has  no 
effect.  For  example, 

exampleX  v.camera  -inSpec  inSpec  -outSpec  -num  111  -nua.vidth  2 
•xanpleX  v.camera  -inSpec  inSpec  -out Spec  -nun  111 


In  these  two  examples,  if  sequence-number  is  123,  w-camera  will  try  to 
find  the  file  with  the  name  123  in  the  current  working  directory. 

Default:  unspecified  (as  long  as  effective  sequence-number  is) 

Example:  -num-width  4 

-suffix  suffix  Optional  argument.  This  option  specifies  the  string  in  the 
file  name  that  follows  the  sequence  digit  string.  If  suffix  is  “.2”,  the 
input  file  is  assumed  to  compressed  by  compress (1). 

Default:  null 
Example:  -suffix  .dat 

-inSpec  inSpec  Required  argument.  inSpec  specifies  the  input  specification 
file.  inSpec  should  be  the  output  spec  file  from  the  dataControl  mod¬ 
ule.  It  contains  the  following  data  items  in  order:  A  sequence  number,  a 
data  record  from  the  image  description  file  at  start-time  (or  end-time)^  a 
data  record  from  the  description  file  for  the  segmented  image  database 
at  3tart-time{oT  end-time), 

-outSpec  outSpec  Required  argument.  outSpec  specifies  the  output  specifi¬ 
cation  file.  It  is  almost  the  same  cis  the  input  inSpec^  except  that  a  file¬ 
name  is  appended  to  the  sequence  number  in  the  file.  More  specifically, 
outSpec  contains  the  following  data  items  in  order:  a  sequence  number. 
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a  image  fiiename(full  path),  a  data  record  from  the  image  description 
file  at  staTi-timt{oT  end-time),  a  data  record  from  the  description  file 
for  the  segmented  image  database  at  3tart-time(oT  end-time). 

-img  imgfile  Optional  argument,  imgfile  specifies  the  file  to  contain  the 
same  data  as  those  contained  in  the  input  file,  which  is  specified  via 
directory,  prefix,  sequence-number,  sequence-number,  suffix.  If  this  op¬ 
tion  is  not  specified,  the  default  path  name  for  imgfile  is  /trap/v^can.  $USER, 
where  $US£R  is  the  login  name  of  the  user. 

Default:  /tmp/w_cam .  $USER 
Example:  -img  "luj/tmp/w. image 

-uc  1  or  0  Optional  argument.  This  switch  has  effect  only  if  the  input  im¬ 
age  file  has  the  suffix  “.Z”.  If  the  input  image  file  is  compressed  and 
-uc  1  is  specified,  the  image  image  will  be  uncompressed  by  using 
uncompress(l)  to  produce  the  output  image  file.  If  the  input  image 
file  is  compressed  but  -uc  0  is  specified,  the  image  will  not  be  uncom¬ 
pressed  and  the  output  image  will  be  tagged  with  “.Z”  to  indicate  that 
the  file  is  still  compressed. 

Default:  1 
Example:  -uc  0 

-help  Optional  argument.  When  this  argument  is  specified,  w.camera  prints 
out  a  brief  help  message  and  exits  gracefully. 

A  complete  example  may  look  as  follows: 

ezampleX  w^camera  -inSpec  inSpec  -outSpec  "luj/tmp/outSpec  \ 
-dir  $HITERT.HOME/data/images  \ 

-prefix  si. img  -num.width  4  -suffix  .Z  \ 

-img  "luj/tmp/w. image  -uc  0 
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This  instructs  v.caBsra  to  read  the  input  spec  file  inSpoc  and  to  find  out 
the  input  image  file  iHITERT.HOME/data/inages/sl .ingOOlO.Z  and  store 
the  input  image  as  the  file  *luj/tnp/w_ image*  Since  the  input  file  name 
has  the  trailing  string  .Z  and  -uc  0  is  specified,  the  output  images  will  be 
* luj/tmp/w_ image. Z  and  “’luj/tmp/w. image l.Z,  provided  that  the  inSpec 
has  two  data  records. 

4.3.3  I/O  File  Specification 

In  this  section,  the  format  of  input  and  output  files  are  explicitly  specified. 
Any  other  programs  wishing  to  communicate  with  v.camera  via  files  must 
follow  the  protocols  or  formats  specified  herein. 

Input  Data  File 

The  input  data  file  as  specified  by  directory^  prefix,  sequence-number,  num- 
width  and  suffix  can  be  in  any  format,  no  interpretation  is  done  on  the 
content  of  this  file.  However,  if  the  file  name  as  specified  above  has  the 
trailing  suffix  “.Z”,  the  input  data  file  is  considered  to  have  been  compressed 
using  compress  (1). 

-inSpec  inSpec 

This  input  spec  file  is  the  same  as  the  output  spec  file  of  the  dataControl 
module.  See  Section  4.2.3. 

•outSpec  outSptc 

It  is  almost  the  same  as  the  input  inSpec,  except  that  a  filename  is  appended 
to  the  sequence  number  in  the  file.  More  specifically,  outSpec  contains  the  fol¬ 
lowing  data  items  in  order:  a  sequence  number,  a  image  filename(full  path), 
a  data  record  from  the  image  description  file  at  start-time(oT  end-time),  a 
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d&ta  record  from  the  description  file  for  the  segmented  image  database  at 
stari-time{oT  end-time).  All  data  fields  are  separated  by  one  or  more  white 
space  characters.  A  typical  outSpec  file  may  look  as  follows: 

0  /tmp/w.img.luj 

tiDe«0. 000000  inag6«sl . iagOOOO  vidth«900  height«900 

2000.000000  -100.000000  -1.400000  0.000000  8.938900  0.000000 
1.570800  0.000000  0.000000  -0.645000  0.000000  0.000000 
0.000000  0.000000  -5.000000  0.000000  0.000000  0.000000 
0.000000  -0.002778  0.000000  0.000000  0.000000  0.000000 
9.000000  0.000000  -1.000000  0.000000  -2500.000000  0.000000 
2002.504682  -0.446386 
time*  0.000000  image*  sl.segOOOO 

seg.ulx*  0  seg.uly*  0  seg.width*  256  seg.height*  256 
tcx*  164.716000  tcy*  444.135000  tvx*  45.836500  tvy*  5.356840 
out.ulx*  -1  out.uly*  -1  out. width*  256  out.height*  256 
size*  46.148500  scale*  2.000000  mag*  5.547310  proj*  2 
roll*  0.000000  pitch*  0.000000  yaw*  1.570800 
estroll*  0.000000  estpitch*  0.000000  estyaw*  1.570800 
500  /tmp/w.img.luj 1 

time*50. 000000  image*sl . img0500  width»900  height*900 

1687.500000  -90.137000  -1.400000  -13.408000  -0.067162  0.000000 
3.146600  0.000000  0.000000  -0.200000  0.000000  0.000000 
0.000000  0.000000  -5.000000  0.000000  0.000000  0.000000 
0.000000  -0.002778  0.000000  0.000000  0.000000  0.000000 
9.000000  0.000000  -1.000000  0.000000  -2500.000000  0.000000 
1689.912994  -13.385272 
time*  50.000000  image*  sl.seg0500 

seg.ulx*  16  seg.uly*  318  seg.width*  256  seg.height*  256 
tcx*  144.383000  tcy*  446.439000  tvx*  13.450800  tvy*  6.849180 
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out.ulx-  -1  out.uly*  -1  out .width-  256  out. height-  256 
size-  15.094200  scale-  2.000000  mag-  16.960100  proj-  2 
roll-  0.000000  pitch-  0.000000  yaw-  3.146600 
estroll-  0.000000  estpitch-  0.000000  estyaw-  3.154900 

-img  imgfile 

imgfile  is  the  actual  output  image  data  file,  imgfile  specifies  the  file  to  contain 
the  same  data  as  those  contained  in  the  input  file,  which  is  specified  via  di¬ 
rectory,  prefix,  sequence-number,  sequence-number,  suffix,  with  the  following 
exception:  if  the  specified  input  file  has  the  trailing  string  “.Z”  and  -uc  1  is 
specified,  then  it  is  assumed  that  the  input  file  has  been  compressed  by  using 
compress (1),  and  w.camera  will  filter  the  input  file  through  uncompress (1) 
and  store  the  results  as  imgfile. 

4.4  Tracking  Camera 

4.4.1  Introduction 

Conceptually,  the  tracking  camera  takes  as  its  input  the  world  view  image 
and  the  control  signals  from  the  tracker,  and  then  finds  out  the  subimage 
from  the  world  view  image.  By  doing  this,  t.camera  effectively  mimics  a 
tracking  camera.  Models  of  the  dynamics  of  the  camera  servomechanism 
may  be  incorporated. 

However,  in  the  batch  mode,  each  individual  program  executes  once  and 
then  dies  or  exits.  There  is  no  mechanism  for  the  tracking  camera  to  get 
any  actual  dynamic  control  signals  from  the  tracker,  since  track  executes 
after  t. earner  a.  Therefore,  in  the  batch  mode,  the  “control  signals”  are  pre¬ 
specified  by  the  user,  and  this  information  is  passed  to  the  display  module 
so  that  the  viewing  box  of  the  tracking  camera  c2Ln  be  displayed  in  the  world 
view  image.  The  main  purpose  for  having  such  a  rather  dumb  tracking 
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camera  in  the  batch  mode  is  that  the  HiTert  system  can  be  more  easily 
modified  to  a  loop  mode  system  with  dynamic  feedback. 

Currently,  no  dynamic  model  is  built-in  for  t.camera  to  simulate  the 
servomechanism.  A  perfect  and  static  model  is  assumed,  i.e.,  the  camera 
can  look  at  whatever  direction  instantly.  Note,  however,  the  dynamics  of  the 
servomechanism  may  be  simulated  by  modifying  the  control  signals  in  this 
ideal  model. 

4.4.2  Command  Line  Options 

Synopsis 

t-camera  -world  worldSpec  -noise  noise-intensity  -o  ouLspec  [-help] 
Options 

-world  worldSpec  Required  argument.  The  input  spec  file  worldSpec  should 
be  the  same  as  the  output  spec  file  of  w.camera  module.  worldSpec 
contains  the  following  data  items  in  order:  a  sequence  number,  a  image 
filename(full  path),  a  data  record  from  the  image  description  file  at 
start-time(oT  end-time)^  a  data  record  from  the  description  file  for  the 
segmented  image  databaise  at  start-time{ov  end-time), 

-noise  noise-intensity  Required  argument,  noise-intensity  specifies  the  file 
containing  three  floating  numbers  representing  white  noise  intensities 
for  X,  y  and  z  directions  respectively.  The  exact  target  position  as  ob¬ 
tained  from  worldSpec  are  perturbed  with  Gaussian  random  values  with 
their  standard  deviations  determined  by  noise  intensities,  respectively. 
The  perturbed  values  are  used  to  simulate  where  the  actual  tracking 
camera  is  looking  at.  By  changing  the  input  noise  intensities,  one  may 
mimic  the  tracking  cameras  with  different  tracking  accuracies. 
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-o  auLspec  Required  argument.  The  output  spec  file  ouLspec  is  almost  the 
same  as  the  input  spec  file  worldSpec,  except  that  additional  informa¬ 
tion  regarding  where  the  the  tracking  camera  is  looking  at  the  pixel 
location  of  the  boresight  in  the  world-view  image. 

-help  Optional  argument.  When  this  argument  is  specified,  t-caaera  prints 
out  a  brief  help  message  and  exits  gracefully. 

4A.3  I/O  File  Specification 

-world  worldSptc 

The  input  file  worldSpec  is  the  world  view  image  spec  file  created  by  camera. 
The  file  format  has  been  specified  in  Section  4.3.3. 

-noise  noise-intensity 

The  input  file  noise-intensity  is  an  ASCII  file  that  contains  the  following 
three  floating  numbers  separated  by  one  or  more  mixed  white  space  ckarac- 
fcrs(blanks,  tabs,  newlines): 


Vi  V2  V3 

where  Vi ,  and  V3  are  the  standard  deviations  of  the  tracking  residual  errors 
in  the  cartesian  inertial  coordinates.  The  units  for  vi,  V2  and  V3  are  meters, 
meters  and  meters ^  respectively. 

A  typical  input  file  track  may  look  as  follows: 

0.5  0.5  0.12 


-o  ouLspec 

The  output  file  ouLspec  consists  of  following  data  items:  a  sequence  number, 
a  image  filename(full  path),  three  inertial  cartesian  coordinates  indicating 
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where  the  tracking  camera  is  looking  at,  two  integers  representing  the  pixel 
location  of  the  tracking  camera  boresight  in  the  world-view  image,  a  data 
record  from  the  image  description  file  at  start-time{oT  end-time),  a  data 
record  from  the  description  file  for  the  segmented  image  database  at  start- 
time(oT  end-time). 

4.5  Image  Processor 

4.5.1  Introduction 

Conceptually,  the  image  processor  segments  the  input  images  from  the  track¬ 
ing  camera  and  outputs  the  segmentation  results,  such  as  the  centroid  pixel 
location,  line-of-sight(LOS)  of  the  target,  etc.  However,  segmentation  is  very 
CPU-intensive  and  is  not  suitable  for  on-line  interactive  simulation.  As  a 
result,  all  the  images  have  been  pregenerate  and  segmented. 

The  centroid  image  processor  ipc  reads  the  description  files  for  the 
world-view  and  segmented  image  databases  and  performs  the  on-line  mea¬ 
surement  from  the  segmentation  results  and  target  range  information.  Given 
the  target  pixel  location  and  camera  states,  the  line-of-sight  of  the  target  can 
be  computed.  With  additional  target  range  information,  target  locations  can 
be  found. 


4.5.2  Command  Line  Options 

Synopsis 

ipc  -iaglnfo  imgInfoFile  -seginfo  seglnfoFile  -inSpec  inSpec  [-dir  di¬ 
rectory}  [-prefix  prefix}  [-num_width  num-width}  [-suffix  suffix}  -outSpec 
outSpec  -aeas  measurement  [-img  imgfile}  [-uc  <1  or  0>]  [-help] 
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Options 

-imginfo  imgInfoFiU  Required  argument.  It  specifies  the  segment  of  the 
description  file  for  the  world-view  image  database.  This  file  should  be 
the  output  of  the  data  control  module.  It  contains  following  items  (See 
Section  4.2.3): 

•  time  at  which  the  image  is  to  be  generated.  This  is  identified  by 
a  “  keyword=value^  pair,  with  the  keyword  being  tine. 

•  the  image  identifier  which  maps  to  the  corresponding  image  file. 
This  is  identified  by  a  “  keyword=value^  pair,  with  the  ke)rword 
being  image. 

•  the  image  width  in  number  of  pixels.  This  is  identified  by  a  “ 
ktyword^valut^  pair,  with  the  keyword  being  width. 

•  the  image  height  in  number  of  pixels.  This  is  identified  by  a  “ 
ktyword^value^  pair,  with  the  keyword  being  height. 

•  the  tank’s  state  at  that  instant  which  includes 

t  xj  yi  zi  xj  yi  zi  R  S  T  R  S  T 

•  the  camera’s  state  which  includes 

^cl  Vcl  ^cl  ^el  Vcl  ^cl  Rc  Tg  Rc  Sc  Tc 

fov  fov  hither  yon  yon 

where  Xc/,  yd-,  ^c/i  ^ciy  Vd^  denote  the  position  and  velocity 
components  of  the  camera  at  the  instant  in  global  inertial  co¬ 
ordinate  system.  Rc-,  5c,  Tc,  Rc^  5c,  Tc  refer  to  the  yaw,  pitch 
,  roll  angles  and  their  rates,  fov  and  fov  refer  to  the  field  of 
view(in  degrees)  and  its  time  rate  of  change(in  degrees  per  sec¬ 
ond),  respectively;  hither^  hither  denote  the  position  of  the  front 
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clipping  plane  and  its  rate  in  the  camera  coordinate  system;  yon, 
yon  position  of  the  back  clipping  plane  and  its  rate  in  the  camera 
coordinate  system.  The  camera  coordinate  system  is  such  that  its 
initial  orientation  aligns  with  the  inertial  coordinate  system,  and 
the  camera  is  always  looking  towards  the  negative  z  direction  of 
the  body-fixed  right-handed  coordinate  system. 

•  range  of  the  target  to  camera  and  range  rate. 

-seglnfo  seglnfoFile  Required  argument.  It  specifies  the  segment  of  the 
description  file  for  the  segmented  image  database.  This  file  should  be 
the  output  of  the  data  control  module.  The  file  is  composed  of  the  data 
records  of  the  following  form  (See  Section  4.2.3): 

t ime*2  image«s 1 . seg0020 

seg_ulx*90  seg_uly*316  seg.width»256  seg.height*256 
tcx*22 1.809  tcy*444.128  tvx*46,5792  tvy«5. 43854 
out.ulx*-!  out.uly*-!  out^width»256  out_height»256 
size»46.8957  scale«2  mag*5. 45893  proj»2 
roll*0  pitch=0  yaw=1.5609 
estroll«0  estpitch=0  estyaw“l .5708 

-inSpec  inSpec  Required  argument.  The  input  spec  file  inSptc  is  the  output 
spec  file  from  the  tracking  camera.  It  consists  of  following  data  items: 
a  sequence  number,  a  image  filename(full  path),  three  inertial  cartesian 
coordinates  indicating  where  the  tracking  camera  is  looking  at,  two  in¬ 
tegers  representing  the  pixel  location  of  the  tracking  camera  boresight 
in  the  world-view  image,  a  data  record  from  the  image  description  file 
at  3tart-time(oT  end-time),  a  data  record  from  the  description  file  for 
the  segmented  image  database  at  start-time{oT  end-time).  See  Sec¬ 
tion  4.4.3. 
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-dir  diredory  Optional  argument.  dirtctoTy  specifies  the  directory  in  which 
a  desired  segmented  input  image  file  resides. 

Default:  the  current  directory. 

Example:  -dir  SHITERT.HOME/data/iMages/scenel.seg 

-prefix  prtfix  Optional  argument.  It  specifies  the  string  that  prtcedes  the 
sequence  or  index  number  in  the  file  name. 

Default:  null 

Example:  -prefix  sl.seg 

-nnm  width  num-width  Optional  argument.  num~width  specifies  the  width 
that  the  numeric  sequence  number  takes.  If  num-width  is  greater  than 
the  number  of  the  digits  that  sequence-number^  has,  sequence-number 
will  be  prepended  with  0’s( zeros)  in  formating  the  file  name  string. 

-suffix  suffix  OptionEil  argument.  This  option  specifies  the  string  in  the 
file  name  that  follows  the  sequence  digit  string.  If  suffix  is  “.Z”,  the 
input  file  is  assumed  to  compressed  by  coiipress(l). 

Default:  null 
Excimple:  -suffix  .dat 

-out Spec  outSpec  Required  argument.  The  output  spec  file  outSpec  is  al¬ 
most  the  same  as  the  input  spec  file  seglnfoFile,  except  it  has  the 
segmented  image  file  name  following  the  word-view  image  filename. 
More  specifically,  outSpec  contains  the  following  data  items  in  order: 
a  sequence  number,  a  image  filename(full  path),  a  segmented  image 
filename(full  path),  a  data  record  from  the  image  description  file  at 
start-time(oT  end-time),  a  data  record  from  the  description  file  for  the 
segmented  image  database  at  start-time(oT  end-time). 


'specified  via  -inSp«c  tnSpec 
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-■•as  measuirment  Required  argument,  measurement  is  the  file  containing 
the  measurement  data  about  the  cartesian  coordinates  of  the  target. 

This  file  has  the  following  format: 

t  x-measure  y-measure  z-measure 

where  x-measure,  y-measure  and  z-measurt  are  position  measurements 
of  the  target  centroid  at  time  t.  These  floating  numbers  x-measure^ 
y-measure  and  z-measure  have  the  following  units,  respectively: 

seconds  meters  meters  meters 

-img  imgfile  Optional  argument,  imgfile  specifies  the  file  to  contain  the 
same  data  as  those  contained  in  the  input  file^  which  is  specified  via 
directory^  prefix^  sequence-number^  sequence-number ^  suffix.  If  this  op¬ 
tion  is  not  specified,  the  default  path  name  for  imgfile  is  /tap/ipIng.lUSER, 
where  $USER  is  the  login  name  of  the  user. 

Default:  /tmp/w-cam .  $USER 
Example:  -img  "luj/tmp/ip.img 

-uc  1  or  0  Optional  argument.  This  switch  has  effect  only  if  the  input  im¬ 
age  file  is  compressed  and  has  the  suffix  “.Z”.  If  the  input  image  file 
is  compressed  2uid  -uc  1  is  specified,  the  image  image  will  be  uncom¬ 
pressed  by  using  uncompress  (1)  to  produce  the  output  image  file.  If 
the  input  image  file  is  compressed  but  -uc  0  is  specified,  the  image  will 
not  be  compressed  and  the  output  image  will  be  tagged  with  “.Z”  to 
indicate  that  the  file  is  still  compressed. 

Default:  1 
Example:  -uc  0 
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4.5.3  I/O  File  Specification 

-imginfo  imgInfoFile 

The  input  ASCII  file  imgInfoFile  is  the  segment  of  the  world-view  image 
database  description  file  of  the  interest.  It  should  be  the  output  of  the 
dataControl  module.  See  Section  4.2.3. 

-seginfo  segInfoFilt 

The  input  ASCII  file  segInfoFile  is  the  segment  of  the  segmented  image 
database  description  file  of  the  interest.  It  should  be  the  output  of  the 
dataControl  module.  See  Section  4.2.3. 

-inSpec  inSpec 

The  input  spec  file  inSpec  is  the  output  spec  file  from  the  tracking  camera. 

See  Section  4.4.3. 

-outSpec  outSpec 

The  output  spec  file  outSpec  contains  the  following  data  items  in  order: 
a  sequence  number,  a  image  filename(full  path),  a  segmented  image  file- 
name(fullpath),  a  data  record  from  the  image  description  file  at  starUtime[ov 
end-time),  a  data  record  from  the  description  file  for  the  segmented  image 
database  at  staTi-time{oi  end-time).  All  these  data  fields  are  separated  by 
the  mixed  white  space  c/iarac/ers(blanks,  tabs,  newlines).  A  typical  output 
spec  file  may  look  as  follows: 

0  /tmp/w.iMg.luj  /tmp/iplmg.luj 

1999,836125  -100.268080  -1.292417  163  445 

time«0. 000000  image*sl . imgOOOO  width«900  hGight*900 

2000.000000  -100.000000  -1.400000  0.000000  8.938900  0.000000 
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1.570800  0.000000  0.000000  -0.645000  0.000000  0.000000 
0.000000  0.000000  -5.000000  0.000000  0.000000  0.000000 
0.000000  -0.002778  0.000000  0.000000  0.000000  0.000000 
9.000000  0.000000  -1.000000  0.000000  -2500.000000  0.000000 
2002.504682  -0.446386 
time*  0.000000  image*  sl.segOOOO 

seg.ulx*  0  seg.uly*  0  seg.width*  256  seg.height*  256 
tcx*  164.716000  tcy-  444.135000  tvx*  45.836500  tvy*  5.356840 
out.ulx*  -1  out.uly*  -1  out.width*  256  out .height*  256 
size*  46.148500  scale*  2.000000  mag*  5.547310  proj*  2 
roll*  0.000000  pitch*  0.000000  yaw*  1.570800 
estroll*  0.000000  estpitch*  0.000000  estyaw*  1.570800 
500  /tmp/w.img.lujl  /tmp/iplmg.lujl 
1687.603661  -89.648265  -1.655478  146  445 
time*50. 000000  image«sl . img0500  width*900  height*900 

1687.500000  -90.137000  -1.400000  -13.408000  -0.067162  0.000000 
3.146600  0.000000  0.000000  -0.200000  0.000000  0.000000 
0.000000  0.000000  -5.000000  0.000000  0.000000  0.000000 
0.000000  -0.002778  0.000000  0.000000  0.000000  0.000000 
9.000000  0.000000  -1.000000  0.000000  -2500.000000  0.000000 
1689.912994  -13.385272 
time*  50.000000  image*  sl.seg0500 

seg.ulx*  16  seg.uly*  318  seg.width*  256  seg.height*  256 
tcx*  144.383000  tcy*  446.439000  tvx*  13.450800  tvy*  6.849180 
out.ulx*  -1  out.uly*  -1  out.width*  256  out.height*  256 
size*  15.094200  scale*  2.000000  mag*  16.960100  proj*  2 
roll*  0.000000  pitch*  0.000000  yaw*  3.146600 
estroll*  0.000000  estpitch*  0.000000  estyaw*  3.154900 
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-meas  measurtment 

The  output  ASCII  data  file  measurement  consists  of  measurement  data.  Each 
instant  is  associated  with  a  data  record  consisting  of  the  four  floating  numbers 
separated  by  the  mixed  white  space  characters: 

t  x-measure  y-measure  z-measure 

The  data  records  making  up  measurement  are  separated  by  one  or  more 
mixed  white  space  c/iarac^ers (blanks,  tabs,  newlines).  Within  each  data 
record^  there  are  four  floating  numbers  x-measure^  y-measure  and  z-measure^ 
which  are  also  separated  by  one  or  more  mixed  white  space  characters,  x- 
measure^  y-measure  and  z-measure  are  the  position  measurements  of  the 
target  centroid  at  the  time  t.  The  units  of  f,  x-measure^  y^measure  and 
z-measure  are  seconds^  meters,^  meters  and  meters,^  respectively. 

A  typical  abridged  measurement  data  file  having  5  data  records  may  look 
as  follows: 


2.000000  2000.109179 
2.100000  2000.205959 
2,200000  2000.203332 
2.300000  2000,213978 
2,400000  2000,211513 


-79.822001  -1.498194 
-78.792146  -1.485431 
-77,740134  -1.485436 
-76,335661  -1.508155 
-75,260915  -1.515856 


Input  Data  File 

The  input  data  file  as  specified  by  directory^  prefix,  sequence-number,  num- 
width  and  suffix  can  be  in  any  format,  no  interpretation  is  done  on  the 
content  of  this  file.  However,  if  the  file  name  as  specified  above  has  the 
trailing  suffix  “.Z”,  the  input  data  file  is  considered  to  have  been  compressed 
using  compress  (1). 
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-img  imgfile 

imgfile  is  the  actual  output  image  data  file,  imgfile  specifies  the  file  to  con¬ 
tain  the  same  data  as  those  contained  in  the  input  file^  which  is  specified  via 
directory^  prefix,  sequence-number,  sequence^number,  suffix,  with  the  follow¬ 
ing  exception:  if  the  specified  input  file  has  the  trailing  string  “ .  Z”  and  -uc 
1  is  specified,  then  it  is  assumed  that  the  input  file  has  been  compressed  by 
using  compreasd),  and  ipc  will  filter  the  input  file  through  uncoapressCl) 
2uid  store  the  results  as  imgfile. 

4,6  Tracker 

4.6.1  Introduction 

track  is  the  tracker  program,  responsible  for  on-line  estimations  of  the 
tracker  states,  based  on  the  measurement  data  from  the  image  processor. 
track  is  an  a-/?-7  Kalman  filter  using  the  position  measurements  of  the  tar¬ 
get  centroid.  The  built-in  Kalman  filter  gains  are:  0.8790,  0.8790,  0.8790.  To 
see  how  the  gains  are  selected,  interested  reader  may  refer  to  Appendix  A. 

The  inertial  reference  coordinate  system  is  shown  in  Figure  1.2.  Even 
thought  the  terrain  in  the  scenario  being  considered  is  flat,  track  does  state 
estimation  for  the  x,  y  and  z  components,  because  the  me2isurement  output 
from  the  image  processor  is  inherently  3-D,  i.e.  it  contains  three  measurment 
outputs  at  each  sampling  instant. 

4.6.2  Command  Line  Options 

Synopsis 

track  -ip  ip-file  [-ic  ic-file^  -o  out-file  [-help] 
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Options 

-ip  ip-file  Required  aurgument.  ip- file  is  the  data  file  containing  the  position 
measurements  from  the  image  processor.  It  should  be  the  output  from 
the  image  processor,  ip-file  has  the  following  format: 
t  x-measure  y-measure  z-measure 

where  x-measure,  y-measure  and  z-measure  are  position  measurements 
of  the  target  centroid  at  time  t. 

-ic  ic-file  Optional  argument.  The  ic-file  contains  the  initial  conditions  for 
the  states  of  the  tracker.  It  consists  of  the  following  data: 

to  xxxyyyzzz 

where  x,  x,  x^  y,  y,  y^  z,  z  and  z  are  the  initial  conditions  at  the  starting 
time  <0-  If  this  option  is  not  specified,  track  will  set  i,  x,  x,  y,  y,  y  i, 
i  and  i  all  to  zeros  as  the  default  values  for  the  initial  conditions. 

-o  out-file  Required  argument,  out-file  contains  the  state  estimation  results. 
It  has  the  following  format: 

txxxyyyzzz 


where  i  ,  i,  i,  y,  y,  y  z^  z^  z  are  the  estimated  states  at  the  time  t. 

-help  Optional  argument.  When  this  argument  is  specified,  track  prints 
out  a  brief  help  message  and  exits  gracefully. 

4.6.3  I/O  File  Specification 

-ip  ip-file 

The  input  ASCII  file  ip-file  is  the  the  measurement  data  file  from  the  image 
processor.  See  Section  4.5.3. 
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-ic  ic-filt 

ic-file  is  the  initial  condition  file,  consisting  of  following  numbers: 
to  xxxyyyzzz 

where  x,  x  and  x  are  the  position,  speed  and  acceleration  of  the  target  at 
time  to.  to  has  the  units  seconds;  whereas  x,  x  and  x  have  units  meters, 
meters  I  seconds  dLnd  meters  I  (seconds)  ,  respectively.  Similar  remarks  apply 
to  y,  y,  y,  i,  i  and  i. 

The  10  floating  numbers  to.  y,  y,  y,  i  and  z  are  separated  by  one 
or  more  mixed  white  space  characters.  A  typical  ic^file  may  look  like  this 

0.0 

2.0000«*»-03 
-1 .0000e-*-02 
-1.4 

-o  ouUfile 

out-file  is  the  output  data  file  produced  by  track.  The  file  contains  the 
estimation  results  for  the  states  of  the  a-fl-y  Kalman  filter,  out-file  consists 
of  the  data  records  of  the  form: 

txxxyyyzzz 

The  data  records  making  up  out-file  are  separated  by  one  or  more  mixed  white 
space  charact€rs(h\sjiksy  tabs,  newlines).  Within  each  data  record,  there  are 
10  floating  numbers  t,  x,  x, ,  x,  y,  y,  y,  i,  z,  z.  x,  x  and  x  are  position,  speed 
and  acceleration  of  the  target  in  inertiail  x  component  at  time  to.  t  has  the 
units  seconds;  whereas  x,  x  and  x  have  units  meters,  meter sj seconds  and 
meter s ! (seconds)^ ,  respectively.  Similar  remarks  apply  to  y,  y,  y,  i,  z,  z. 

A  typical  abridged  out-file  having  5  data  records  may  look  like  this 


O.OOOOe-fOO 

O.OOOOe+00 

0 


0.0000e*»«00 

O.OOOOe+00 

0 


2.0  2000.139048  0.067167  -0.042767 
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-79.399693  11.831204  1.019657 
-1.500131  0.045759  0.060516 

2.1  2000.130446  0.028983  -0.080865 

-78.425036  11.453766  0.481003 
-1.494273  0.054009  0.062987 

2.2  2000.171127  0.106619  0.015452 

-77.462902  11.085122  0.012754 
-1.484086  0.070346  0.074265 

2.3  2000.198152  0.144723  0.056529 

-76.494522  10.771683  -0.340856 
-1.477363  0.076240  0.072543 

2.4  2000.220910  0.168341  0.076715 

-75.338722  10.917937  -0.138229 
-1.484948  0.048538  0,033268 

4.7  Predictor 

4,7.1  Introduction 

predict  is  the  predictor  program,  responsible  for  computing  the  future  posi¬ 
tion  of  the  target.  The  prtdicUahead  or  lead  time  is  the  time  of  the  expected 
flight  time  of  the  projectile  intercepting  the  target,  predict  is  used  in  con¬ 
junction  with  the  a-/?-7  Kalman  filter.  The  prediction  equation  used  by 
predict  is  as  the  follows: 

f.(t  +  (p|()  =  i,(f)  + 


where  t  is  the  current  time,  tj,  the  predxct-ahead  or  lead  time,  f,(^  +  tp|0  the 
predicted  target  p>osition  at  the  future  time  t-^tp  given  the  estimates  at  the 
present  time  t;  i,(0?  ^i(0  the  estimates  of  the  current  position, 
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speed  and  acceleration,  respectively.  The  subscript  i  applies  to  each  x,  y  and 
z  component,  respectively. 

4.7.2  Command  Line  Options 

Synopsis 

predict  -i  in^file  [-tp  tp]  -o  ouUfile  [-help] 

Options 

-i  in- file  Required  argument,  in- file  is  the  input  file  containing  the  state 
estimation  results  from  the  a-^-7  tracker.  The  file  has  the  following 
format: 

txxxyyyzzz 


where  x,  x  and  x  are  the  position,  speed  and  acceleration  of  the  target 
at  time  Iq.  i  has  the  unit  of  seconds;  whereas  x,  x  and  x  have  units  of 
meters,  meters  I  seconds  and  meter  s  /  {seconds)^ ,  respectively.  Similar 
remarks  apply  io  y,  y,  y,  z,  z  and  z,  respectively.  These  data  are 
separated  by  one  or  more  mixed  white  space  characters. 

-tp  tp  Optional  argument,  tp  is  the  predict-ahead  or  lead  time,  which  is 
the  expected  flight  time  of  the  projectile  intercepting  the  target,  tp  is 
a  floating  number  and  has  the  unit  of  seconds. 

Default:  2 
Example:  -tp  1 

-o  out- file  Required  argument,  out- file  is  the  output  data  file  produced  by 
predict.  This  file  has  the  following  format: 
t  t,  i(t,\t)  y(tf\t)  z(t,\t) 
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where  t  is  the  current  time,  tj  the  future  time(^/  =  ^  H-  ^p),  x(tf\t), 
y(t/\t)  and  z(tf\t)  the  predicted  target  position  coordinates  at  based 
on  the  current  state  estimates  at  t. 

-help  Optional  ^Lrgument.  When  this  argument  is  specified,  predict  prints 
out  a  brief  help  message  and  exits  gracefully. 

4.7.3  I/O  File  Specification 

-i  in-file 

This  input  file  in-file  to  predict  is  the  output  state  estimation  file  from 
track.  The  file  format  has  been  specified  in  Section  4.6.3. 

-o  out-file 

out-file  is  the  output  data  file  produced  by  predict.  The  file  consists  of  the 

data  records  of  the  form; 

t  tf  x(li\t)  y(lf\t)  z(tf\t) 

The  data  records  making  up  out-file  are  sep£Lrated  by  one  or  more  mixed 
white  space  characters{b\anks,  tabs,  newlines).  Within  each  such  a  data 
record,  t  is  the  current  time,  tj  the  future  time(^/  =  t  +  tp),  y(tj\t) 

and  z(tj\t)  the  predicted  target  position  at  tj  based  on  the  current  state 
estimates  at  t.  These  floating  numbers  are  separated  by  one  or  more  mixed 
white  space  characters,  t.  tf,  x{tf\t),  y(tf\t)  and  z(tf\t)  have  the  following 
units,  respectively: 

seconds  seconds  meters  meters  meters 
A  typical  abridged  out-file  having  5  data  records  may  look  as  follows: 

2.000000  4.000000  2000.187848  -53.697971  -1.287581 
2.100000  4.100000  2000.026682  -54.555498  -1.260281 
2.200000  4.200000  2000.415269  -55.267150  -1.194864 
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2.300000  4.300000  2000.600656  -55.632868  -1.179797 
2.400000  4.400000  2000.711022  -53.779306  -1.321336 

4.8  Error  Analysis 

4.8.1  Introduction 

errAnaly  is  the  program  that  performs  the  error  analysts  for  the  HiTert 
system.  errAnaly  takes  as  its  inputs  the  prediction  data  and  the  reference 
exact  data,  and  computes  prediction  errors  as  well  as  the  statistics  on  the 
error  data. 

Two  types  of  errors  are  computed  depending  on  the  command  line  option 
specified:  inertial  component  errors  and  dartboard  errors  .  The  inertial  com¬ 
ponent  errors  are  computed  by  finding  the  differences  between  the  predicted 
target  positions  and  the  actual  target  positions  in  each  inertial  component 
X,  y  and  2,  respectively.  More  specifically,  the  inertial  component  errors  are 
defined  as  follows: 


c,(0  =  i,(0  - 

where  c,(<)  is  the  error  at  f,  f,(f)  the  predicted  inertial  target  position  co¬ 
ordinate,  Xi{t)  the  exact  inertial  target  position  coordinate.  The  subscript  i 
applies  to  each  inertial  x,  y  and  z  component,  respectively.  These  errors  are 
used  subsequently  to  perform  the  error  statistics. 

The  dartboard  errors,  on  the  other  hand,  are  the  perspective  projections 
of  the  inertial  error  vectors  onto  the  dartboard  as  seen  by  an  observer^ 
Figure  4.2  shows  the  dartboard  at  an  arbitrary  instant  t.  Point  P  is  the 
predicted  position  of  the  target  at  Po  the  exact  position,  O  the  location  of 
the  observer.  The  dartboard  tt  is  centered  on  the  point  Pq,  the  inertial  error 

vector  at  this  instant  is  given  by  PqP.  The  perspective  projection  of  PqP 


'Currently,  the  observer  is  fixed  on  the  tracking  camera. 
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Figure  4,2:  Deimitions  of  the  dartbo&rd 


onto  the  dartboard  plane  ir  is  given  by  PqP*.  Note  that  the  intersection  of 
the  line  OP  and  the  dartboard  plane  t  is  P*,  The  components  of  PqP*  in 
the  x^y'  plane  are  the  dartboard  errors.  Appendix  B  has  the  derivations  on 
how  to  find  the  dartboard  errors.  Please  note  that  the  dartboard  errors  are 
mainly  intended  for  graphical  displaying  purpose.  The  error  statistics  are 
still  computed  based  on  the  inertial  component  errors. 

4.8«2  Command  Line  Options 

Synopsis 

•rrAnaly  -prsd  predfile  -exact  exactJUe  [-showOart  showDart'}  [-tbf  tbf] 
C-tburst  tburst]  -outSpec  outSpec  [-outErr  oatE’rr]  [-help] 
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t «  end  time 

t ,  predict-ahead  or  lead  time 

—  exact  trajectory 
----  predicted  trajectory 

Figure  4.3:  Definition  of  the  burst  interval 

Options 

-pred  predfile  Required  argument,  predfile  is  the  data  file  containing  the 
prediction  results  from  predict.  The  file  has  the  following  format: 
t  if  xitf\t)  y(tj\t)  mf\t) 

where  t  is  the  current  time,  tj  the  future  time(</  =  t  -j-  tp)j  x(tj\t), 
y(tj\t)  and  z{tf\i)  the  predicted  target  position  coordinates  at  based 
on  the  current  state  estimates  at  t.  These  floating  numbers  f/, 
x(t/|t),  y(tf\t)  and  have  the  following  units,  respectively: 

seconds  seconds  meters  meters  meters 

-exact  exactfile  Required  argument,  exactfile  contains  the  exaurt  positions 
of  the  target.  This  file  has  the  following  format: 
t  x(t)  y(t)  z(t) 

where  t  is  the  current  time,  x(t),  y(t)  and  2(t)  the  exact  target  position 
coordinates  at  t.  These  floating  numbers  t,  x(f),  y{t)  and  z(t)  have  the 
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following  units,  respectively: 

seconds  meters  meters  meters 

-showDart  showDart  Optional  argument.  This  boolean  argument  showDart 
specifies  whether  or  not  the  dartboard  errors  should  be  computed.  If 
showDart  is  false,  i.e.,  O(zero),  errAnaly  will  compute  the  inertial 
component  errors  and  write  the  error  data  to  a  file(see  option  “-outErr 
outErr*  *);  otherwise,  errAnaly  will  compute  the  dartboard  errors  and 
aind  write  the  error  data  to  a  file.  Note  the  error  data  computed  are 
intended  for  graphical  displaying  purpose.  The  statistics  are  always 
computed  based  on  the  inertial  component  error  data. 

Default:  1 

Ex2Lmple;  -showDart  0 

-tbf  ibf  Optional  argument,  tbf  is  the  track-before- fire  time(See  Figure  4.3). 
tbf  is  a  floating  number  and  has  the  unit  of  <ieconds. 

Default:  tp 
Example:  -tbf  5 

-tburst  tburst  Optioned  argument,  tburst  is  the  burst  interval  over  which 
projectiles  are  fired  to  intercept  the  target(See  Figure  4.3).  tburst  is 
a  floating  number  and  hsLS  the  unit  of  seconds.  The  relevant  statistics 
diie  computed  based  on  the  data  during  this  burst  internal. 

If  tburst  is  not  specified,  the  default  value  of  {endJime  —  start  Jime  — 
tbf)  is  used,  where  start. time  and  end  Jime  are  the  instants  at  which 
the  tracking  system  starts  amd  terminates,  respectively,  start  Jime 
and  endJime  are  controlled  by  the  data  control  module.  errAnaly 
determines  the  values  of  start  Jime  and  endJime  from  the  numbers  in 
the  input  data  files. 
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If  tburst  is  specified  and  is  greater  than  {endJime  —  start  Jime  —  tbf), 
tburst  will  be  set  to  {endJime  —  start  Jime  —  tbf)  by  errAnaly. 

Default:  [endJime  —  start  Jime  —  tbf) 

Example:  -tburst  10 

-outSpec  outSpec  outSpec  contains  the  name  or  path  of  the  file  containing 
computed  error  data,  and  prediction  error  statistics.  The  file  has  the 
following  format: 


to 

U 

tbf 

np 

rithf 

^burat  ^burst^end 

max\t^\ 

rms,^ 

max|,^l 

rms,^ 

max|,,| 

rms^^ 

max|,^,l 

rms,^^ 

showDart 

error  Data  Filename 


tburst 


where  to,  te,  tp^  tbf  and  tburst  are  the  start Jime^  endJime^  predict- 
ahead  time^  track-before- fire  time^  burst  interval,  respectively;  max|g^|, 
me,,  rmSe-  are  the  maximum  absolute  error,  mean  and  RMS  (Root  Mean 
Square)  value  of  errors  in  inertial  x,  inertial  y,  inertial  azimuth  and 
elevation  components,  respectively;  showDart  is  a  boolean  having  the 
meaning  as  that  specified  under  the  option  “-showDart  showDart^ . 
error DataFilename  is  the  path  of  the  file  containing  the  error  data(see 
below). 

-out  Err  out  Err  Optional  argument.  outErr  specifies  the  name  or  path  of 
the  file  to  contain  the  computed  error  data.  If  this  option  is  not  spec- 
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iiied,  the  default  path  name  for  outErr  is  /tap/v^caa .  $USER,  where 
$USER  is  the  login  name  of  the  user. 

The  format  of  the  file  outErr  depends  on  the  boolean  flag  showDart 
specified.  If  showDart  is  false,  i.e.,  0,  outErr  contains  the  inertial 
component  errors  and  has  the  following  format: 
t  if  Cx(t/|t)  ^v(^/IO 


If  showDart  is  true,  i.e.,  non-zero,  outErr  contains  the  dartboard  errors 
and  has  the  following  format: 

t  tf  dx(tj\t)  dy{tf\i) 

Default:  /tmp/errAnaly  .$USER 

-help  Optional  argument.  When  this  argument  is  specified,  errAnaly  prints 
out  a  brief  help  message  and  exits  gracefully. 

4.8,3  I/O  File  Specification 

-pred  predfile 

predfile  is  an  input  file  to  errAnaly.  This  file  contains  the  prediction  results 
from  predict.  See  Section  4.7.3. 

-exact  exactfile 

The  input  ASCII  file  exactfile  contains  the  reference  exact  data  of  the  target 
trajectory.  It  should  be  the  output  of  dataControl.  See  Section  4.2.3. 

A  typical  exactfile  having  5  data  records  may  look  as  follows: 


2.000000  2000.100000  -79.946000  -1.400000 
2.100000  2000.200000  -78.837000  -1.400000 
2.200000  2000.200000  -77.718000  -1.400000 
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2.300000  2000.200000  -76.590000  -1.400000 
2.400000  2000.200000  -75.453000  -1.400000 


-outSpec  outSpec 

exactfile  is  an  output  file  from  errAnaly.  The  file  contains  the  following  data, 
which  are  separated  by  one  or  more  mixed  white  space  characters {hldxiks^ 
tabs,  newlines). 


to 

tc 

tp 

tbf 

np 

ntbj 

^burst 

^burst^end 

max!,,j 

rms,^ 

max|,,l 

^ty 

rms,^ 

max\i^\ 

me. 

rmse. 

max|,.,l 

rms,^^ 

showDart 

error  Data  Filename 


tburst 


where  to^  fg,  tp,  tbf  and  tburst  are  the  start Jime^  endJime^  predict-ahead 
time,  track-before-fire  time,  burst  interval,  respectively,  and  they  have  the 
unit  of  seconds]  maxjej,  m<,,  rmSe,(t  tcdces  x,  y,  or  z)  are  the  maximum  abso¬ 
lute  error,  mean  and  RMS  (Root  Mean  Square)  value  of  the  errors  in  inertial 
X,  y  and  z  components,  respectively,  and  they  have  the  unit  of  meters;  when  i 
takes  az  or  el,  maxj<,|,  are  the  errors  in  the  aizimuth  and  elevation 

components,  respectively,  and  they  have  the  unit  of  radians;  showDart  is  a 
boolean  having  the  meaning  as  that  specified  under  the  option  “-showDart 
showDart^ ,  error  Data  Filename  is  the  path  of  the  file  containing  the  error 
data  and  is  the  same  as  the  file  name  outErr, 
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-outErr  outEir 

outErr  is  an  output  file  from  errAnaly.  The  contents  or  format  of  the  file 
depends  on  the  boolean  flag  showDart  specified  via  the  command  line  option. 

If  showDart  is  false,  i.e.,  0,  outErr  contains  the  inertial  component  errors 
and  is  composed  of  the  data  records  of  the  form: 
t  t, 

These  data  records  are  separated  by  one  or  more  mixed  white  space  charac- 
^ers(blanks,  tabs,  newlines).  Within  each  data  record,  there  are  5  floating 
numbers  t,  tf,  ej;(tf\t),  €y(tf\t),  e^itflt),  which  are  also  separated  by  one 
or  more  mixed  white  space  characters,  t  is  the  current  time,  tj  the  future 
time(^y  =  t  ^p);  ej;(tj\t),  ty(tj\t),  e^(tf\t)  are  the  inertial  component  pre¬ 
diction  errors  at  tj  based  on  the  current  state  estimates  at  t.  t,  tf,  Cx(i/|i)» 
Cy(^/|<),  Cg(tf\t)  have  the  units  of  seconds,  seconds.,  meters,  meters  and 
meters,  respectively. 

If  showDart  is  true,  i.e.,  non-zero,  outErr  ontains  the  dartboard  errors 
and  is  composed  of  the  data  records  of  the  form: 
t  if  dSs\t)  dy{tf\t) 

These  data  records  are  separated  by  one  or  more  mixed  white  space  charac¬ 
ters.  Within  each  data  record,  there  are  4  floating  numbers  t,tf,  dx(tf\t)  and 
dy(tf\t),  which  are  also  separated  by  one  or  more  mixed  white  space  char¬ 
acters.  t  is  the  current  time,  tf  the  future  time(f/  =  f  +  tp);  dr(tf\t)  and 
dy(tf\t)  are  the  dartboard  component  errors,  t,  tf,  dx(tf\t)  and  dy{tf\t)  have 
the  units  of  seconds,  seconds,  meters,  meters  ,  respectively 

4.9  Instrumentation  Module 

4.9.1  Introduction 

xhitert  is  the  instrumentation  module  program,  responsible  for  display¬ 
ing  world-view  images,  tracking  camera  images,  segmented  images  and  error 
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analysis  results.  The  program  must  be  executed  under  the  XI 1  windowing 
environment. 


Figure  4.4:  The  window  arrangement. 


During  its  execution,  xhitert  will  pop  up  a  window  of  almost  a  full¬ 
screen  size.  This  window  consists  of  6  subwindows(See  Figure  4.4).  The 
world-view  image  displayed  has  been  shrinked  by  a  factor  of  2  in  order  to  fit 
into  the  window.  The  red  box  in  the  world  view  image  indicates  where  the 
tracking  camera  is  looking  at.  Also  displayed  are  the  corresponding  tracking- 
camera  image,  which  is  not  scaled,  and  the  segemented  binary  image,  which 
is  normalized.  In  the  hatch  mode,,  only  images  corresonding  to  a  single  user 
specified  instant  are  displayed^. 

In  the  subwindow  displaying  the  trajectories,  the  red  curve  is  the  pre¬ 
dicted  trajectory,  while  the  green  curve  is  the  exact  trajectory. 

xhitert  is  built  on  top  of  Xlib.  It  runs  much  faster  on  a  display  support¬ 
ing  8-bit  pseudo-color  than  on  a  monochrome  display,  since  on  monochrome 
display  xhitert  has  to  dither  the  large  color  images  to  black  and  whtie  ones. 

^However,  the  dartboard  and  trajectory  windows  display  the  results  for  the  whole  time 
period  of  the  operation. 
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4.9.2  Command  Line  Options 

Synopsis 

xhitert  -world  worldSpec  -camera  cameraSpec  -ip  ipSpec  -pred  predfile 

-exact  exactfile  -errSpec  errSpec  [-display  display"]  [-demo  demo]  [-help] 

Options 

-world  worldSpec  Required  argument.  worldSpec  is  world-view  image  spec 
file.  It  should  be  the  output  spec  file  of  the  w. camera  module.  It 
contains  the  following  data  items  in  order:  A  sequence  number,  a  data 
record  from  the  image  description  file  at  start-time(oT  end-time)^  a  data 
record  from  the  description  file  for  the  segmented  image  database  at 
start-time(or  end-time). 

-camera  cameraSpec  Required  argument.  It  should  be  the  output  spec  file 
of  t. camera  module.  cameraSpec  consists  of  following  data  items:  a 
sequence  number,  a  image  filename(full  path),  three  inertial  cartesian 
coordinates  indicating  where  the  tracking  camera  is  looking  at,  two 
integers  representing  the  pixel  location  of  the  treicking  camera  boresight 
in  the  world-view  image,  a  data  record  from  the  image  description  file 
at  start-time(oT  end-time),  a  data  record  from  the  description  file  for 
the  segmented  image  database  at  start-tim€(oT  end-time). 

-ip  ipSpec  Required  argument.  It  should  be  the  output  spec  file  from  the 
ipc  module.  ipSpec  contains  the  following  data  items  in  order:  a  se¬ 
quence  number,  a  image  filename(full  path),  a  segmented  image  file- 
name(fullpath),  a  data  record  from  the  image  description  file  at  start- 
fimc(or  end-time),  a  data  record  from  the  description  file  for  the  seg¬ 
mented  image  database  at  start-time(oi  end-time). 
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-pred  prtdfile  Required  argument,  prtdfile  is  the  input  file  containing  the 
prediction  data  from  predict.  It  should  be  the  output  of  the  predictor. 
This  file  has  the  following  format: 

t  tf  i(</|<)  y{t/\t)  z{tj\t) 

where  t  is  the  current  time,  tj  the  future  i\me{tf  =  t  +  fp),  x(tf{t), 
y(tf\t)  and  z{tf\t)  the  predicted  target  position  coordinates  at  tj  based 
on  the  current  state  estimates  at  t. 

-exact  exactfile  Required  argument,  exactfile  is  the  input  file  containing 
the  reference  exact  trajectory  data.  It  should  be  the  output  of  the 
dataControl  module.  This  file  has  the  following  format: 
t  x{t)  y{t)  z{t) 

where  t  is  the  current  time,  x(t),  y(t)  and  z(t)  the  exact  target  position 
coordinates  at  t.  These  floating  numbers  t,  x{t),  y(t)  and  z{t)  have  the 
following  units,  respectively: 

seconds  meters  meters  meters 

-errSpec  errSpec  Required  argument.  errSpec  is  the  error  spec  file  from 
errAnaly.  input  spec  file  has  the  following  format: 

to  tc  tp  tbf  tburst 

^P  ^tbf  ^burst^cnd 

max(e,|  m,,  rms,, 

mai|ej  m,^  rms<^ 

max|e,|  m,,  rms,^ 

max|c^^l  m^^^  rms^^, 

shawDart 
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error  Data  Filename 

where  to^  tp^  tbf  and  tburst  are  the  start Jime^  endJime^  predict- 
ahead  time,  track-before-fire  time^  burst  interval^  respectively; 

rm3«,  are  the  maximum  absolute  error,  mean  and  RMS  (Root  Mean 
Square)  value  of  errors  in  inertial  x,  inertial  y,  inertial  x,  azimuth  and 
elevation  components,  respectively;  skowDart  is  a  boolean  having  the 
meaning  as  that  specified  under  the  option  “-showDart  showDarC  in 
errAnaly.  error  Data  Filename  is  the  path  of  the  file  containing  the 
error  data. 

-display  display  Optional  argument,  display  specifies  where  to  display  the 
images  and  the  results.  It  is  a  string  of  the  format  “host rdisplay .-screen”. 

Default:  $DISPLAY 
Example:  delta:0 

-demo  demo  Optional  argument.  This  boolean  flag  demo  specifies  whether 
or  not  to  display  the  tracking  results  in  a  pseudo  real-time  mode.  If 
demo  is  false,  i.e.,  0,  all  the  tracking  results  will  be  blasted  to  the 
screen  almost  at  the  same  time;  if  demo  is  true,  however,  xhitert  will 
be  in  the  pseudo  real-time  mode,  displaying  the  tracking  results  one  at 
a  time. 

Default:  0 
Example:  -demo  1 

4.9.3  I/O  File  Specification 

-world  worldSpec 

worldSpec  is  an  input  spec  file  produced  by  w.camera.  See  Section  4.3,3. 
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-camera  cameraSpec 

cameraSpec  is  an  input  spec  file  produced  by  t. camera.  See  Section  4.4.3. 
-ip  ipSpec 

ipSpec  is  an  input  spec  file  produced  by  ip. 

-pred  predfile 

predfile  is  an  input  data  file  produced  by  predict.  See  Section  4.7.3. 

-exact  exactfile 

exactfile  is  an  input  data  file  containing  the  exact  reference  trajectory  data. 
See  Section  4.8.3. 

-errSpec  errSpec 

errSpec  is  an  input  spec  file  produced  by  errAnaly.  See  Section  4.8.3. 
Image  Data  File 

The  input  image  data  file  as  specified  by  ImageFileName  in  the  worldSpec 
must  be  a  Khoros  viff  image.  See  Section  4.3.3. 

Error  Data  File 

The  input  error  data  file  as  specified  by  error DataFilename  is  produced  by 
errAnaly.  The  error  data  file  has  the  format  as  specified  in  Section  4.8.3. 


Chapter  5 

World-view  Image  Database 


5.1  Introduction 

One  of  the  important  part  in  the  simulation  of  the  HiTert  system  is  to  simu¬ 
late  the  image  acquiring  system.  Various  factors  and  considerations  lead  to 
the  decision  of  building  an  image  database  by  pregenerating  a  temporal  se¬ 
quence  of  images.  Individual  images  in  the  database  can  be  can  be  retrieved 
or  played  back  for  the  study  of  image  processing  algorithms  and  the  tracking 
system.  With  the  tool  of  the  image  generation  program,  different  scenarios 
can  be  simulated  to  study  the  HiTert  system.  In  this  chapter,  discussions 
will  be  concentrated  on  the  specific  scene  that  has  been  constructed  and  the 
images  of  which  have  been  actually  stored  on  the  disk. 

5.2  Trajectory  Data 

The  scenario  under  the  consideration  is  illustrated  in  Figure  1.2  and  repro¬ 
duced  in  Figure  5.1.  First,  the  geometric  trajectory  that  a  land  vehicle, 
equipped  with  certain  driving  logic,  may  traverse  is  envisioned  or  proposed. 
It  is  then  endowed  with  the  time  information,  i.e.  the  velocity  and  the  head¬ 
ing  angle  profiles  of  a  generic  tank  along  the  trajectory  are  designed.  Note 
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that  on  a  flat  terrain  the  velocity  and  the  heading  angle  profiles  completely 
determines  the  trajectory,  given  the  initial  conditions.  It  is  assumed  that 
heading  direction  of  the  vehicle  is  along  the  tangential  direction  of  the  tra¬ 
jectory.  This  assumption  is  generally  valid  for  a  tracked  vehicle(e,g.  tank) 
with  no  skidding.  Differentiation  of  the  heading  angle  with  respect  to  time 
yields  the  angular  velocity  of  the  tank.  The  product  of  the  angular  velocity 
<ind  the  speed  at  a  point  along  the  trajectory  gives  the  centripetal  acceleration 
of  the  tank.  This  centripetal  acceleration  depends  on  the  lateral  frictional 
characteristics  between  the  terrain  and  the  track,  and  is  constrained,  under 
the  no-skidding  condition,  by  the  following  equation: 

On  =  iJV  <  fitg 

where  an  is  the  centripetal  acceleration,  uj  the  angular  velocity  of  the  tank, 
V  the  forward  speed,  fit  the  lateral  frictional  coefficient,  g  the  gravitational 
constant. 

The  velocity  profile  is  designed  in  such  a  way  that  its  time  rate  of  change 
falls  within  the  acceleration  and  deceleration  capability  of  a  generic  tank(e.g. 
Ml  tank).  From  the  velocity  profile  and  heading  angle  profile,  the  trajec¬ 
tory  can  be  constructed  through  the  numerical  integration.  The  constructed 
trajectory  can  further  be  examined  to  see  if  it  is  indeed  the  desired  one. 

Since  a  target  may  take  any  maneuvers  as  the  driver  deems  necessary  in 
the  real  environment,  the  trajectory  produced  from  the  above  is  realistic  as 
long  as  the  dynaimic  constraints  are  not  violated. 

The  trajectory  data  used  in  generating  image  database  are  plotted  in 
Figure  1.3  and  is  reproduced  in  Figure  5.2.  One  of  the  important  features 
in  the  plots  is  that  when  the  tank  makes  a  turn  it  decelerates,  while  when  it 
travels  along  a  straight  path  it  accelerates  or  keeps  at  a  higher  speed. 
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Figure  5.1:  Scenario  under  consideration 
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Y(feet) 


Figure  5.2:  Trajectory  data 


5.3  Scenario 

The  tracking  scenario  is  illustrated  in  Figure  5.1.  The  global  inertiaJ  coordi¬ 
nate  system  is  fixed  on  the  flat  earth,  with  positive  x  pointing  to  North,  y 
to  East  and  z  vertically  down. 

At  t  =  0  secona,  the  tank  is  located  at  (6561.7,-328.1,0.0)  feet  or 
(2000,-100,0)  meters,  traveling  east  with  a  speed  of  20  mph.  The  subse¬ 
quent  states/maneuvers  of  the  tank  can  be  seen  from  Fig.l.  The  house  is 
located  at  (6561.7, 262.5, 0)  ft  and  the  tree  at  (6594.5,295.3,0)  ft. 
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The  camera,  fixed  at  (0.0, 0.0, —16.4)  ft,  is  5  ineters(16.4  ft)  above  the 
ground  and  haa  a  constant  view  amgle  of  9  degrees.  The  depth  of  the  field 
is  determined  by  the  hither  and  yon  clipping  planes  of  the  camera.  The 
hither  and  yon  clipping  planes  are  1  meter(3.3  ft)  and  2500  meters  (8202.1 
ft),  respectively,  away  from  and  in  front  of  the  camera. 

5.4  Image  Generation 

A  C  program  named  tank  has  been  written  to  do  image  rendering,  tank 
is  built  on  top  of  the  3-D  graphics  library  Dore( Dynamic  Object  Render¬ 
ing  Environment),  tank  has  two  interfaces  with  Dore:  one  for  the  dynamic 
Tenderer^  the  other  for  the  production  Tenderer.  The  dynamic  rendercr  can 
achieve  near  real-time  response,  but  requires  special-purpose  graphics  hard¬ 
ware.  As  a  result,  the  dynamic  renderer  interface  of  tank  only  nms  on  the 
Stardent  machine.  The  production  renderer,  on  the  hand,  relys  on  the  soft¬ 
ware  for  .scene  rendering,  and  can  run  both  on  a  Sun  and  Stardent  machine, 
provided  the  Dore  library  is  available. 

The  image's  were  generated  with  the  aid  of  Dore  on  Stardent  3000(titan 
P3)  machine.  Titan  P3  is  a  supermini  graphics  computer.  It  has  1280  x  1024 
color  display  which  supports  double  buffering  and  24-bit-per-pixel  image. 
Because  of  the  hardware  problem,  the  dynamic  renderer  could  not  be  run  in 
multi-user  mode.  As  a  result,  the  ray-tracer  was  used  to  generate  the  images. 
At  the  time  of  image  generation,  the  machine’s  configuration  was  3  cpus  with 
256MB  RAM. 

Since  it  was  expected  that  the  resulting  images  would  adso  be  displayed 
on  a  Sun  workstation,  which  typically  has  a  screen  size  of  1152  x  900  pixels, 
the  dimension  of  the  images  was  chosen  to  be  900  x  900  pixels. 

tank’s  production  renderer  takes  the  trajectory  data  as  input  and  gen¬ 
erates  a  frame  of  image  for  each  sampling  instant.  The  trajectory  data  were 
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sampled  at  the  .1  second  from  0*  second  to  lOQth  second  inclusive.  1001 
images  were  generated  aifter  64  hours(38-hour  cpu  time)  of  running  at  the 
highest  elevated  user  priority. 

The  images  generated  by  the  Dore  production  Tenderer  are  in  Dore  raster 
file  format  and  had  24  bits  per  pixel,  with  each  RGB  chamnel  having  8  bits. 

A  900  X  900  image  in  Dore  rasterfile  format  takes  about  2.43  MB  disk  space. 

This  means  that  the  total  images  would  consume  2.43  GB(2430  MB)  disk 
space,  which  is  prohibitively  expensive  and  unfeasible.  For  this  reason,  at 
the  run  time,  each  Dore  raster  image  was  converted  to  viff  format  image 
and  a  color  compression  code  was  introduced,  which  compressed  the  24- 
bit-per-pixel  image  to  8  bits  per  pixel.  This  resulted  in  a  reduction  of  2/3 
disk  storage,  eind  only  810  MB  storage  was  needed.  The  8- bit  images  were 
further  compressed  using  unix  file  compressing  utility  compress (l),  resulting 
in  about  another  95%  compression.  The  images  are  finally  in  8-bit  viff  format, 
stored  as  *  .Z  files,  which  consume  only  4  MB  of  disk  space.  Compared 
to  2430  MB  storage  originally  required,  this  is  a  very  significant  reduction. 

The  whole  conversion  process  is  automatically  done  by  the  image-generation 
program  if  the  command  line  option  “-c”  to  the  program  is  specified. 

5.5  I/O  File  Specification 

5.5.1  Command  Line  Options 
Synopsis 

tank  [-X  xstarti  [-y  ystart"]  [-W  width']  [-H  height]  [-procs  processors] 
[-dt  devicetype]  [-i  datafile]  [-o  imgfile imgf He]  [-debug]  [  z]  [-track] 
[-help] 
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Options 

“X  xstart  Optional  argument.  It  specifies  the  horizontal  position  in  pixels  of 
the  upper  left  corner  of  the  Dore  window  relative  to  upper  left  corner 
of  the  root  window.  This  option  has  effect  only  for  the  dynamic  ren- 
derer  running  under  the  windowing  environment  and  will  be  ignored 
the  image  is  written  to  a  file. 

Default:  0 
Example:  -x  20 

-y  ystart  Optional  argument.  It  specifies  the  vertical  position  in  pixeb  of 
the  upper  left  corner  of  the  Dore  window.  This  option  has  effect  only 
for  dynamic  Tenderer  running  under  the  windowing  environment  and 
will  be  ignored  the  image  is  written  to  a  file. 

Default:  0 
Example:  -y  20 

-W  xoidth  Optional  argument.  Specifies  the  width  in  pixels  for  the  Dore 
window.  In  the  case  that  the  image  is  written  to  a  file,  the  image 
width  can  be  larger  than  the  screen  width. 

Default:  128 
Excimple:  -W  512 

-H  Optional  argument.  Specifies  the  height  in  pixels  for  the  Dore 

window.  In  the  case  that  the  image  is  written  to  a  file,  the  image 
width  can  be  larger  than  the  screen  height. 

Default:  128 
Example:  -H  512 

*procs  processors  Optional  argument.  Specifies  the  number  of  processors 
to  be  used.  The  default  is  that  only  1  CPU  is  going  to  be  usedfi.e. 
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processors  takes  the  value  of  0).  The  value  of  1  tells  Dore  to  run  in  a 
multiprocessor  mode,  but  only  with  one  processor.  This  mode  is  usually 
used  for  debugging  purpose  and  is  less  efficient  than  specifying  0(true 
uniprocessor  operation).  In  the  case  that  the  number  of  processors 
specified  are  more  than  that  of  machine’s  actual  configuration,  the 
actual  number  of  CPUs  will  be  used. 

Default:  0 
Example:  -procs  2 

-dt  devicetype  Optional  argument.  Specifies  the  type  of  rendering  devices 
to  be  used,  devicetype  can  only  be  one  of  the  following  strings: 

•  ardentxll  A  dynamic  XI 1  window  device  will  be  used.  This  op¬ 
tion  is  valid  only  if  the  underlying  hardware  supports  the  dynamic 
renderer, 

•  rasterf  ile  The  production  renderer  will  be  used  and  the  output 
of  the  image  is  written  to  a  disk  file. 

•  seq_rasterf ile.  The  production  renderer  will  still  be  used  but 
a  sequence  of  image  files  will  be  produced.  In  this  case  the  corre¬ 
sponding  output  data  file  must  be  specified.  See  below. 

Default:  ardentxll 
Example:  -dt  seq_rasterf ile 

-i  datafile  Optional  argument.  Specifies  the  input  data  file  which  contains 
the  states  of  the  tank.  The  position  and  orientation  information  will 
be  used  to  position  the  taink  in  the  image.  The  velocity  information 
will  be  used,  together  with  the  camera’s  state,  to  compute  the  range 
rate,  which  will  be  output  to  the  description  file. 

Since  right  now  the  camera  is  fixed,  the  input  data  file  only  contains  the 
state  information  about  the  tank,  while  the  camera’s  state  information 


CHAPTER  5.  WORLD-  VIEW  IMAGE  DATABASE 


79 


is  haxd-coded  in  the  program.  This  relieves  the  burden  of  inputting 
data  about  camera’s  state  information.  The  input  data  file  consists  of 
data  records  of  the  following  form: 

t  yi  zi  xi  yi  zi  R  S  T  R  S  t 

where  x/,  y/,  x/,  x/,  y/,  i/  denote  the  position  and  velocity  components 
of  the  tank  at  the  instant  t  in  global  inertial  coordinate  system.  R^  S, 
T,  R^  5,  T  refer  to  the  Eulerian  angles  and  their  rates. 

Default:  dynamics.dat 
Example:  "/data/ tank.dat 

-o  imgfile  Optional  argument.  Specifies  the  filename  for  the  output  image. 
This  option  should  be  specified  only  if  the  production  Tenderer  is  used 
and  the  output  of  the  image  is  written  to  a  disk  file.  This  option  also 
depends  on  the  specification  of  “-dt  devicetype'^ . 

•  If  ‘'-dt  rasterfile”  is  specified,  the  default  file  name  for  the 
image  is  tank .  img. 

•  If  “-dt  seq_rasterf  ile”  is  specified,  this  option  must  be  speci¬ 
fied  and  take  the  following  format: 

-o  ssceneNumber .  im^image Number 
For  example,  if  '‘-o  sl.imglO”  is  specified,  a  sequence  of  image 
files  will  be  produced:  sl.imgOOlO,  sl.imgOOll,  sl.ing0012,  ... 
depending  the  number  of  data  records  contained  in  the  input  data 
file  datafile.  In  this  case  the  default  is  si .  imgO. 

-c  Optional  argument.  This  option  should  be  specified  only  if  the  produc¬ 
tion  Tenderer  is  used  and  the  output  of  the  image  is  written  to  a  disk 
file.  If  this  option  is  specified,  the  output  Dore  reister  image  file  will 
be  converted  to  viff  image  format  and  the  resulting  viff  image  is  com- 
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pressed  from  24-bits-per  pixel  to  8  bits  per  pixel.  This  viff  byte  image 
is  further  compressed  using  cospressd). 

-debug  Optional  argument.  If  specified,  tank  will  print  out  some  debugging 
information. 

-track  Optionzd  argument.  This  option  is  valid  only  if  a  XI 1  dynamic  device 
is  used.  If  the  dynamic  tenderer  is  used  and  this  option  is  specified, 
a  primitive  tracker  will  be  started  and  communication  between  the 
tracker  and  the  camera  is  established  via  BSD  sockets.  This  way  the 
target  will  be  always  locked  at  the  center  of  camera  view. 

-help  Optional  argument.  When  this  argument  is  specified,  tank  prints  out 
a  brief  help  message  and  exits  gracefully. 

5.5.2  Input  Data  File 

The  input  data  file  to  the  image  generation  program  contains  the  complete 
state  information  about  the  tank  and  the  camera  at  the  sampling  instants. 
Since  right  now  the  camera  is  fixed,  the  input  data  file  only  contains  the 
state  information  about  the  tank,  while  the  camera’s  state  information  is 
hard-coded  in  the  program.  This  relieves  the  burden  of  inputting  data  about 
camera’s  state  information.  The  input  data  file  consists  of  data  records  of 
the  following  form: 

^  yi  yi  zi  R  S  T  R  S  t 

where  x/,  y/,  x/,  x/,  y’/,  x/  denote  the  position  and  velocity  components  of 
the  tank  at  the  instant  t  in  global  inerti2Ll  coordinate  system.  R,  5,  T,  R,  5, 
T  refer  to  the  Eulerian  angles  and  their  rates. 

Note  that  program  can  handle  the  input  data  file  quite  flexibly.  The 
input  data  record  can  be  written  almost  any  way  the  user  wants,  as  long 
as  there  is  the  right  number  of  data  fields  and  those  fields  are  separated 
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by  white  space  characters{spac€y  tab»  newline  character(s)).  A  typical  input 
data  record  can  take,  for  example,  the  following  form: 

t 

X/  y/  zi 

X/  yi  zi 

R  S  T 
R  S  t 

5.5.3  Output  Description  File 

The  output  of  the  program  consists  of  two  parts:  a  single  description  file  and 
a  temporal  sequence  of  raster  image  files.  The  description  file  and  those  image 
files  constitute  the  image  database.  All  the  files  reside  in  the  same  directory. 
The  primary  image  file  retrieving  tool  is  v.ceunera.  which  is  described  in 
Section  4.3.  The  more  sophisticated  image  database  management  is  left  for 
the  future  development. 

The  description  file  will  be  described  in  this  section  amd  the  raster  image 
files  in  next  section. 

The  quantities  in  the  description  file  are  in  SI  units(  i.e.  length  in  meters, 
time  in  seconds,  mass  in  kilograms,  single  in  radians)  unless  explicitly  stated 
otherwise.  The  description  file  contains  the  following  information: 

•  time  at  which  the  image  is  to  be  generated.  This  is  identified  by  a 
keyword^value^  pair,  with  the  keyword  being  time. 

•  the  image  identifier  which  maps  to  the  corresponding  image  file.  This  is 
identified  by  a  “  keyword =value^  pair,  with  the  keyword  being  image. 

•  the  image  width  in  number  of  pixels.  This  is  identified  by  a  “  key- 
word=valu€”  pair,  with  the  keyword  being  width. 
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•  the  image  height  in  number  of  pixels.  This  is  identified  by  a  “  key- 
rvord=valu€^  pair,  with  the  keyword  being  height. 

•  the  tank’s  state  at  that  instant  which  includes 

t  xi  yi  zi  XI  yi  zi  R  S  T  R  S  t 

•  the  camera’s  state  which  includes 

^cl  Vcl  ^cl  ^cl  yd  ^cJ  Rc  Sc  Tc  Rc  Sc  Tc 
fov  fov  hither  yon  yon 


where  x^/,  yd^  id^  Vd,  Zd  denote  the  position  and  velocity  compo¬ 
nents  of  the  camera  at  the  instant  in  global  inertial  coordinate  system. 
Rc,  Sc,  Tc,  Rc,  Sc,  Tc  refer  to  the  yaw,  pitch  ,  roll  angles  and  their  rates. 
fov  and  fov  refer  to  the  field  of  view(in  degrees)  and  its  time  rate  of 
change(in  degrees  per  second),  respectively;  hither,  hither  denote  the 
position  of  the  front  clipping  plane  and  its  rate  in  the  caunera  coordi¬ 
nate  system;  yon,  yon  position  of  the  back  clipping  plane  and  its  rate  in 
the  camera  coordinate  system.  The  camera  coordinate  system  is  such 
that  its  initial  orientation  aligns  with  the  inertial  coordinate  system, 
and  the  camera  is  always  looking  towards  the  negative  z  direction  of 
the  body-fixed  right-handed  coordinate  system. 

•  range  of  the  target  to  camera  etnd  range  rate. 

A  typical  data  record  in  the  output  description  file  may  look  like  this: 

time«0. 500000  image*sl . imgOOOS  width»900  height»900 
2000.000000  -95.388000  0.000000  0.044456  9.504300  0.000000 
1.566100  0.000000  0.000000  0.006405  0.000000  0.000000 
0.000000  0.000000  -5.000000  0.000000  0.000000  0.000000 


CHAPTER  5,  WORLD-VIEW  IMAGE  DATABASE 


83 


0.000000  -0.002778  0.000000  0.000000  0.000000  0.000000 
9.000000  0.000000  -1.000000  0.000000  -2500.000000  0.000000 
2002.279668  -0.816753 

5.5.4  Image  Files 

Image  Data  Format 

The  images  in  the  database  are  in  Khoros  viff  image  format.  For  detailed 
information  about  viff  image  file  format,  please  refer  to  the  Khoroe  Reference 
Manual. 

Image  File  Name 

The  image  file  names  have  the  following  format: 

sNAmgXXXX 

For  example,  sl.iagOOOO,  sl.imgOOOl,  sl.img0002,  ...,  sl.iEglOOO.  si 
stands  for  scene  1 ;  imgOOOl  corresponds  to  the  image  at  .lih  second,  iMg0002 
at  .2th  second,  ...,  imglOOO  at  lOOth  second. 


Chapter  6 
Conclusions 

6.1  Summary  of  Achievements 

With  the  very  limited  resources,  we  have  successfully  established  the  non- 
real  time  simulation  capability  for  the  passive,  optically-based  hierarchical 
tracking  system.  The  achievements  include: 

•  An  image  generation  tool,  which  allows  us  to  generate  the  temporal 
sequence  of  images  of  different  scenarios. 

•  An  image  database  and  image  retrieval  tool(w_cafliera).  The  scen«irio 
for  the  established  image  database  is  simple,  yet  possesses  the  com¬ 
plexity  to  test  the  HiTert  system  against  a  real  environment. 

•  An  image  processor,  which  segments  the  images  and  outputs  target 
centroid  position  information. 

•  A  tracker,  which  performs  the  optimal  estimation  of  the  target  states. 

•  A  predictor,  which  attempts  to  predict  the  future  position  of  the  target, 
based  on  the  state  estimation  results  from  the  tracker. 

•  An  error  analysis  module,  which  can  compute  the  dartboard  errors  in 
addition  to  computing  the  error  statistics  for  the  tracking  system. 
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•  An  instnimentation  module,  which  displays  the  status  of  the  HiTert 
system  during  its  operation.  More  specifically,  this  instrumentation 
module  can  display  the  world-view  image,  tracking  camera  image,  seg¬ 
mented  image,  projectile  hit  points,  trajectories,  and  error  analysis 
results, 

•  A  set  of  file-based  IPC  protocols  amd  a  generic  subsystem,  which  con¬ 
sists  of  the  world-view  image  database,  tracking  camera,  image  proces¬ 
sor,  tracker,  predictor,  error  anadysis  and  displaying/control  module. 

With  such  a  testbed,  we  can  plug  in  a  different  image  processor,  tracker  or 
predictor  with  minimum  efforts  to  study  the  different  image  processing  and 
tracking  algorithms.  This  generic  subsystem  lays  the  foundation  upon  which 
we  can  build  multi-level  tracking  system  and  further  study  various  aspects 
of  the  HiTert  system. 

The  non-real  time  simulation  allows  the  pre-generation  of  raw  images  and 
pre-segmentation  of  those  imageries.  It  also  the  allows  the  separate  study  for 
image  processing  and  tracking  algorithms.  These  achievements  realize  the 
hierarchical  target  tracking  system  proposed  in  1989. 

6.2  Future  Research 

This  research  on  the  Hierarchical  Target  Extraction,  Recognition  and  Track¬ 
ing  System  is  inherently  multi-disciplineury  in  nature  ctnd  covers  diverse  ac¬ 
tive  research  fields.  We  have  built  a  prototype  for  the  HiTert  system.  More 
in-depth  study  is  needed  in  further  exploring  the  multi-disciplinary  environ¬ 
ment  existing  at  Purdue.  Many  problems  need  to  be  addressed  in  the  full 
implementation  of  the  HiTert  system.  These  problems  include: 

•  Battle  field  scene  simulation: 

~  Terrain  rendering  for  the  rough  surface. 
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~  Target  motion-blur  simulation. 

-  Environment  simulation. 

•  Image  database  management. 

•  Image  Processing:  Extraction  of  the  target  orientation  information. 

•  Tracking:  More  advanced  tracker  need  to  be  developed 

-  Utilization  of  elevation  data  from  a  digital  terrain  map. 

—  Utilization  of  orientation  information 

•  Coordination  of  the  subsystems. 


Appendix  A 

a-/?-7  Tracker  Design 


A.l  Introduction 

The  classical  problem  of  the  fire  control  system  is  the  accurate  prediction  of 
the  future  position  of  a  target  at  the  time  of  the  projectile  intercept.  Once  the 
future  position  of  the  target  has  been  obtained,  the  corresponding  gun  point¬ 
ing  lead-angles  can  be  determined.  Current  approaches  to  the  solution  of  this 
problem  typically  consists  of  two  parts:  estimation  and  prediction[12,  13]. 
Kalman  filtering  techniques  are  employed  to  estimate  the  velocity  and  accel¬ 
eration  of  the  target  based  on  the  noisy  measurements  of  the  target  positions. 
Based  upon  the  estimate  for  the  velocity  cind  acceleration,  a  prediction  of  the 
future  position  of  the  target  can  be  ascertained. 

One  of  the  key  issues  in  the  modeling  of  the  target  dynamics  has  been 
how  to  model  the  target  acceleration [12,  13,  14,  15,  16].  Singer[12]  used 
the  temporally  exponentially  correlated  acceleration  model,  viewing  the  ac¬ 
celerations  as  the  perturbations  to  the  constant  velocity  trajectory.  Berg(13] 
proposed  the  addition  of  the  acceleration  correction  term  to  the  Singer  model, 
which  represents  an  adaptive  estimate  of  the  mean  target  jerk(time  rate  of 
the  change  of  the  target  acceleration).  Kendrick  et  al.[14]  suggested  to  use 
the  orientation  measurements  to  improve  the  estimate  of  the  air-borne  target 
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acceleration.  Andrisani  et  al.[15,  16)  further  extended  the  idea  of  incorpora¬ 
tion  of  orientation  measurements  into  the  trackers  by  developing  nonlinear 
dynamic  models  of  fixed-wing  aircraft  and  helicopters  for  extended  Kalman 
filters  (19). 

Thus  far,  the  ground  vehicle  tracking  remains  to  be  an  open  research 
area.  Because  of  the  resource  constraints,  however,  it  is  not  our  intent  to 
address  advanced  trackers  for  the  ground  vehicles  here.  Instead,  a  simple  non- 
adaptive  tracker  will  be  developed  for  the  prototype  HiTert  system. 

A.2  Target  State  Estimator  Equation 

A. 2.1  State  Equation 

In  a  single  physical  dimension,  the  target  state  equations  may  be  represented 
by 

i  =  Fx  4*  Gw  (A.l) 

where 
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X  is  the  target  state  vector;  x^,  x,  and  x^  are  the  inertial  position,  velocity  and 
acceleration  in  ith  component  of  the  inertial  Cartesian  coordinate  system.  A 
is  the  system  matrix,  B  the  input  vector;  w  is  the  zero-mean  white  noise 
process  with  intensity  Q,  It  is  assumed  that  the  target  jerking  term  as 
modelled  by  the  white  noise  intensity  Q  is  the  same  in  each  inertiaJ  Cartesian 
coordinate.  Also  assumed  is  that  the  exogenous  white  noise  process  in  e£w:h 
dimension  is  independent  of  or  uncorrelated  with  each  other. 
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A.2.2  Measurement  Equation 

A  single  passive  optical  sensor  can  only  yield  the  bearing  angles  or  addition¬ 
ally  bearing  angle  rates.  The  absence  of  range  measurements  will  lead  to 
the  lack  of  observability  in  certain  scenarios [17].  To  remedy  this,  one  may 
assume  availability  of  either  the  range  measurements  or  another  passive  op¬ 
tical  sensor  to  triangulate  the  target.  For  now,  we  assume  for  simplicity  that 
the  position  measurements  are  available  indirectly  via  the  transformation  of 
the  measurement  data.  Also  the  measurements  are  discrete  in  nature  and  are 
available  at  the  sampling  instants.  With  these  assumptions  the  measurement 
equation  can  be  written  as 

2(k)  =  Cx(k)  +  v(k)  (A.2) 

where  z  is  the  measured  position  of  a  single  dimension  of  the  inertial  cartesian 
coordinate  systems,  x  the  state  vector,  v  the  zero-mean  white  noise  process 
with  intensity  R;  C  is  the  measurement  vector  and  has  the  following  value: 

C= [  1  0  0  I 

A.2. 3  Discretization 

Let  T  denote  the  sampling  period.  It  is  well  known[20,  21]  that  the  solution 
to  the  linefir  time  invariant  state  equation  (A.l)  is 

x{t  +  T)  =  e”'i(t)  + 

T 

=  x(t)  +  f  Gw(t T  —  a)d(T  (A. 3) 

F  = 


Since 


0  1  0 
0  0  1 
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is  in  Jordan  form,  A  is  nilpotent.  It  is  easy  to  see  that 

1  t  012  ' 

0  1  t  (A.4) 

,00  1  J 

Also  note  that  under  the  zero-order  hold  approximation, 

ti;(t  -h  T  —  O’)  =  for  0  <  (7  <  r  (A.5) 

Therefore 

j  1  ff  (tV2  1  r  0 ' 

0  I  (T  0  w{t)d(T 

[  0  0  1  J  L  1  J 

■  rV6  ] 

rV2  u;(t)  '(A.6) 

Finally,  combining  the  Equations  (A.3)-(A.6)  gives,  with  the  slight  abuse  of 
the  notations,  the  state  equation  can  be  written  as 

x(fc  +  1)  =  Ax(fc)  +  Bu;(fc)  (A. 7) 

where 

■  1  T  TV2  ]  r  rV6  ' 

A=  0  1  T  ,  B=  rV2 

,00  I  J  L  ^  , 

Using  the  observability  test(20,  21],  it  is  easy  to  see  that  the  {C,  A}  in  Equa¬ 
tions  (A.2)  and  (A.7)  form  an  observable  paur. 


A.3  Target  State  Estimator  Gains 

Kalman  filter  provides  the  optimal  solution  in  the  sense  of  minimizing  the 
mean  square  estimation  error.  In  general,  it  can  also  be  easily  implemented. 
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The  Kalman  filter  state  equations  are[21] 

x(fcH-l)  =  i4x(l;)  (A.8) 

x(A:)  =  x(k)  +  £(A:)[y(A:)  -  Cx{k)]  (A. 9) 

where 

L{k)  =  M(k)C'^iCM{k)C‘^  +  R)~'  (A.IO) 

P(k)  ^  f;{[x(fc)  -  x(<:))[x(t)  -  x(^)n 

=  M(k)-M(k)C^(CM(k)C'^  +  R)'^CM(k)  (A.ll) 

Af(Jt  +  l)  =  f;{[x(it+l)-i(ifc+l)][x(it+l)-x(A:  +  l)f} 

=  AP{k)A^  +  BQB^  (A.12) 

A/(0)  =  f;{i(0)x^(0)}  (A.13) 

The  steady-state  Kalman  filter  gain  is  given  by 

L  =  MC^(CMC^  +  fl)'* 


M  =  A{M  -  MC'^iCMC'^  +  R)~''CM)A^  A  BQB^ 

It  should  be  noted  that  the  state  estimator  governed  by  Equations  (A.8) 
and  (A. 9)  is  also  known  as  the  currtni  estimaior[2l]  because  the  estimate 
of  x(^)  uses  the  measurements  up  to  and  including  those  at  k.  However, 
the  image  based  measurement  process  is  time-consuming  compared  to  the 
sampling  period  T.  Thus,  it  is  not  realistic  assuming  the  measurement  y(k)  is 
available  for  the  estimation  of  x{k) .  Therefore,  the  one-step  ahead  prediction 
estimator  should  be  used  instead.  Substituting  (A. 9)  into  (A.8)  yields  state 
equation  for  the  prediction  estimator 

x(k  +  1)  =  Ax{k)  -I-  F(A:)[y(fc)  -  Cx{k)]  (A. 14) 


where 


F{k)  =  AL(k) 


(A.15) 
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A. 4  Predictor  Equation 


A  simple  second-order  predictor  is  employed  using  the  following  equation 

+  MO  =  Pi(0  +  (A-16) 

where  tp  is  the  projectile  time-of-flight,  p,(f)»  ^*(0  current 

estimate  for  the  position,  velocity  and  the  acceleration  in  the  ith  inertial 
Cartesian  coordinate,  respectively.  Implicit  in  the  above  prediction  equa¬ 
tion  is  the  assumption  that  the  target’s  linear  velocity  and  acceleration  are 
constant  during  the  time-of-flight  interval. 

The  performance  of  a  predictor  is  often  evaluated  in  terms  of  the  predic¬ 
tion  error.  The  performance  metric  used  here  is  the  average  prediction  error 
distance,  which  is  defined  as 


€d  = 


d-  (y  -  y)^  -f  -  zy] 
N 


(A.17) 


where  (i,  y,  z)  is  the  predicted  position  of  the  target,  (x,  y,  z)  the  correspond¬ 
ing  exact  position  of  the  target,  N  the  number  of  the  prediction  data  points. 


A. 5  Numerical  Results 

Taking  the  image  processor  capability  into  account,  the  measurement  noise 
covariance  is  assumed  to  have  the  value  H  =  0.1  w}.  The  white  noise  co- 
variance  Q  modelling  the  target  jerking  is  somehow  arbitrary.  In  fact,  Q  is 
a  design  parameter  at  our  disposal.  Figure  A.l-a  shows  the  RMS  2-second 
prediction  error  td  vs.  the  ratio  of  QjR.  The  suboptimal  prediction  occurs  at 
Q/H  =  270.  The  corresponding  optimal  Kalmcin  filter  gain  is  0.5057,  1.1352 
and  1.2755.  Figure  A.Tb  shows  the  parametric  behavior  of  the  prediction 
error  Cd  vs.  the  prediction  lead  time  tp,  when  the  design  parameter  Q/F 
varies.  For  comparison.  Figure  A. 2  shows  the  RMS  prediction  error  for  an 
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(b)  Parametric  behavior 


Figure  A.l:  a-p-'y  tracker  RMS  prediction  error 
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Figure  A.3:  a-/3  tracker  RMS  estimation  error(<p  =  0  second) 


a-fi  tracker.  It  can  be  seen  from  the  plots  that  the  suboptimal  tracker 
can  achieve  the  approximately  same  performance  as  the  the  suboptimal  o- 
/?-7  tracker.  This  is  mainly  because  the  non-adaptive  nature  of  the  trackers, 
which  are  employed  for  the  state  estimation  for  the  whole  time  history  of  the 
trajectory  consisting  of  the  various  segments  of  different  maneuvers.  How¬ 
ever,  it  should  be  noted  that  the  behavior  of  the  prediction  error  versus  Q/R 
may  not  be  the  same  as  the  state  estimation  error  versus  Q/R.  Figure  A.3 
show  the  a-/9  tracker  RMS  estimation  error(tp  =  0  second)  versus  the  ratio 
Q/R.  Note  that  Figure  A.3-a  and  Figure  A.3  has  the  different  abscissa  scale. 

A.6  Conclusions 


A  simple  a-^-'y  tracker /predictor  has  been  designed  to  minimize  the  predic¬ 
tion  error.  Comparison  shows  that  the  a-^-7  tracker  and  a- 13  tracker  can 
achieve  the  approximately  same  performance.  This  suggest  that  advanced 
tracker  design  method  need  to  be  studied  £tnd  the  ground  vehicle  tracking 
still  remains  to  be  an  open  research  area. 


Appendix  B 

Dartboard  Analysis 


While  the  prediction  errors  in  each  inertial  Cartesian  components  are  good 
metrics  of  the  performance  of  a  tracking  system,  it  is  often  desirable  to  have 
the  tracking  results  graphically  displayed  in  a  form  suitable  for  human  con¬ 
sumption.  This  is  particulau-ly  important  for  the  operator  of  a  fire  control 
system.  The  dartboard  analysis  presented  here  mimics  the  fictitious  target- 
carried  dartboard  as  seen  by  an  observer. 

B.l  Definitions 

Figure  B.l  is  a  schematic  at  an  arbitrary  instant  t.  Point  Po  is  the  exact 
position  of  the  target  at  Point  P  the  predicted  position  at  t',  O  the  location 
of  the  observer.  The  up  direction  of  the  observer  at  the  time  t  is  specified  by 
the  unit  vector  u. 

The  eye  coordinate  system  Oxyz  is  determinated  as  follows:  the  positive 
z  direction  is  opposite  to  the  vector  OPo,  i.e., 

z^^Wol\oK\  (B.l) 

*The  prediction  was  performed  at  (f  —  fp),  where  tp  is  the  predict>ahead  or  lead  time. 
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Figure  B.l:  Dartboard  schematic 


the  x-axis  is  determined  by 

z  =  u  X  z  (B.2) 

cLnd  the  y-axis  completes  the  triad  of  the  right-hand  coordinate  system: 

y  =  zxx  (B.3) 

Note  that  the  up  direction  is  not  necessarily  perpendicular  to  the  line 
of  sight(LOS)  of  the  observer.  The  only  requirements  for  the  up  direction 
vector  u  are  that  u  is  in  the  ^verticaF  plane  determined  by  the  y  and  z  axes 
and  that  u  has  a  positive  component  along  the  y  axis. 

The  dartboard  plane  tt  contains  the  point  Pq  and  is  perpendicular  to 
the  vector  OPq.  The  x'-axis,  y'-axis  and  z'-axis  of  the  dartboard  coordinate 
system  P^Py'z*  are  parallel  to  the  Ox,  Oy  and  Oz  axes,  respectively. 
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The  hit  point  P*  of  a  projectile  is  the  intersection  of  the  line  OP  and 
the  dartboard  plane  tt.  The  vector  PqF*  is  the  perspective  projection  of  the 
prediction  error  vector  PqP  onto  the  dartboard  plane  tt.  The  vector  PqP^ 
is  the  dartboard  error  vector.  Resolving  the  vector  PqP*  in  the  coordinate 
system  Pax^y^z*  yields  the  dartboard  error  components^. 

It  should  be  pointed  out  that  both  the  location  and  the  orientation  of 
the  dartboard  plane  tt  change  with  the  time.  The  location  and  up  direction 
of  the  observer  also  change  with  the  time  if  the  observer  is  traveling  with 
a  moving  vehicle.  However,  in  computing  the  dartboard  error  vector  PP', 
it  is  assumed  that  the  observer  and  the  dartboard  are  fixed  during  the  time 
interv2J  that  it  takes  for  a  projectile  to  travel  from  P  to  P* . 

B.2  The  Hit  Point 

We  shall  derive  the  vector  equation  for  finding  the  hit  point  P'.  In  the 
following,  we  use  an  arrow  above  a  single  upper  case  letter  to  denote  the 
position  vector  for  the  corresponding  point.  All  the  position  vectors  have  the 
common  starting  point,  say,  O/,  which  is  the  origin  of  the  inertial  reference 
frame. 

Let  v\  and  ui  be  the  unit  direction  vectors  for  OPq  and  OP,  respectively. 
The  vector  form  equation  for  the  line  OP  is  given  by 

P  =  0-hpvi  (B.4) 

where  P  is  the  position  vector  of  an  arbitrary  point  P  on  the  line,  p  a  real 
scalar  quantity^,  O  the  position  vector  of  the  point  O. 

The  vector  form  equation  for  the  dartboard  plane  tt  is 

(P-Po)•v^^0  (B.5) 

^The  error  component  in  the  z'  axis  is  always  zero 

^The  absolute  value  of  p  is  the  distance  between  the  points  P  and  O. 
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where  P  is  the  position  vector  of  an  arbitrary  point  P  on  the  plane,  Pq  the 
position  vector  of  the  point  Pq.  Substituting  Equation  B.4  into  B.5  gives 

(0  -f  pV2  —  Po) '  vi  =  0  (B.6) 


Solving  Equation  B.6  for  p  yields 

p  =  (B.7) 

Vi  ^2 

Substituting  p  back  into  Equation  B.4  gives  the  hit  point  P* 

P>  =  6  (B.8) 

Vi  •  V2 

The  solution  for  the  position  vector  P'  of  the  the  hit  point  P'  is  independent 
of  ^uly  coordinates  system,  since  vectors  are  coordinates  system  independent*. 


B.3  Coordinate  Transformation 

The  coordinates  of  the  hit  point  position  vector  P'  in  Equation  B.8  can 
be  most  conveniently  resolved  in  the  inertial  Cartesian  coordinate  system 
Oixiyizi,  as  all  the  relevant  vector  quantities  in  the  right  hand  side  of  Equa¬ 
tion  B.8  are  usually  expressed  in  the  inertiad  coordinate  system.  Given  the 
inertial  coordinates  of  these  vectors,  finding  the  coordinates  for  the  position 
vector  P'  is  quite  trivial. 

However,  to  find  out  the  dartboard  errors,  the  inertial  coordinates  for  P' 
must  be  transformed  into  the  the  dartboard  coordinate  system  Pox^y'z'.  This 
transformation  can  be  done  in  the  two  steps:  translation  and  then  rotation. 

First,  the  inerticd  coordinate  system  Oixiyjzi  need  to  be  translated  to 
the  origin  Pq  of  the  dartboard  coordinate  system.  The  application  of  this 

^All  the  position  vectors,  however,  have  the  same  reference  point. 
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translation  transformation  to  the  hit  point  P*  effectively  yields  the  dartboard 
error  vector  PoP\  where 

Kp^  =  P'-Pq  (B.9) 

Next,  we  need  to  apply  the  rotation  transformation  to  the  dartboard 
error  vector  PqP*.  Since  the  dartboard  coordinate  system  has  the  same  orien¬ 
tation  as  the  eye  coordinate  system  Oxyz^  we  can  use  the  direction  matrix 
of  the  coordinate  system  Oxyz  relative  to  the  inertial  coordinate  system 
Oixiyizj.  The  direction  cosine  matrix  which  transforms  from  Oixiyjzi  to 
Oxyz  is  given  by 


Xi 

X2 

X3 

yi 

1/2 

ys 

Z2 

(B.IO) 


where  xi,  xj  and  X3  are  the  components  of  the  unit  vector  x  in  the  inertial 
X/,  j//  and  zi  directions,  respectively.  Similar  remarks  apply  to  j/i,  j/a,  2/3,  zi, 
Z2  and  Z3.  The  unit  vectors  x,  y  and  z  of  the  eye  coordinat^e  system  Oxyz 
are  given  by  Equations  B.l  ^  B.3. 

Concatenating  the  translation  and  rotation,  we  have  the  dartboard  error 
components  x\  y'  and  2'  given  by 


x'  ■ 

i 

Xi  X2  X3 

{^')i 

y 

z' 

j 

yi  2/2  j/3 

.  Z\  Z2  Z3 

{PoP'h 

.  (PoP')3  . 

(B.ll) 


where  (PqP*)\  {  PqP*)2  and  (PoP')3  are  the  inertial  components  of  the  databoard 
error  vector  PqP^  in  the  x/,  yi  and  Z{  directions,  respectively. 


Appendix  C 

Geometrical  Transformation 

C.l  Introduction 

Geometrical  transformation  is  one  of  the  core  parts  of  3-dimensional  com¬ 
puter  graphics.  In  addition  to  its  importance  in  the  modelling  and  render¬ 
ing  object  hierarchies,  geometrical  transformation  is  also  an  integral  part  of 
the  image-based  tracking  system.  For  example,  given  a  world  coordinate 
(Xu,i  yw.  ^w)  what  is  the  corresponding  point  in  the  image  ?  Conversely,  given 
a  screen  coordinate  (j,,!/,)  what  is  the  corresponding  line-of-sight(LOS)  in 
the  world  ?  To  answer  these  questions,  a  series  of  geometrical  transforma¬ 
tions  must  be  performed  to  yield  the  solution. 

A  thorough  discussion  of  the  subject  is  beyond  the  scope.  We  shall 
outline  the  highlights  of  the  geometrical  transformation  by  deriving  or  sum¬ 
marizing  the  key  formulas  from  an  engineering  point  of  view,  leaving  aside 
other  graphics  issues  such  as  clipping,  hidden  surface  removed  and  lighting 
models.  Interested  readers  may  refer  to  Foley  et.  el. [9]  or  Newman  et.  el. [10]. 

Since  the  images  are  generated  with  the  aid  of  3D  graphics  system 
Dorefll],  discussions  will  follow  Dore  conventions  when  necessary. 
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C.2  Viewing  Transformation 

C.2.1  World  to  Eye  Coordinate  TVansformations 

In  order  to  simplify  the  transformations  of  world  coordinates  into  the  graph¬ 
ical  output  device  coordinates^  the  world  coordinates  are  first  transformed 
into  the  eye  coordinates  system.  The  eye  coordinate  system  relative  to  the 


Figure  C.l:  World  to  eye  coordinate  transformation 

world  coordinate  system  is  completely  determined  by  the  location  and  ori¬ 
entation  of  the  eye  coordinate  system.  The  eye  point  or  the  location  of  the 
camera  is  given  by  the  position  (See  Figure  C.l).  Suppose 

that  the  camera  is  looking  at  Po(the  center  of  interest).  To  be  consistent  with 
Dore  3D  graphics  system,  which  is  used  to  generate  the  world  view  images 
of  a  simply  battle  field  scene,  the  positive  direction  of  the  Zc  axis  is  opposite 
to  the  camera  boresight.  Also  assume  that  the  up  direction  of  the  camera  is 
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given  by  the  unit  vector  u^.  The  orientation  or  the  unit  vectors  /,  m  and  n 
of  the  camera  coordinate  system  are  then  given  as  follows: 


EPo 

\EPo\ 

u  X  n 
n  X  I 


(C.l) 

(C.2) 

(C.3) 


A  column  vector  will  be  used  to  represent  the  coordinates  of  a  point. 
The  direction  cosine  matrix,  which  transforms  the  world  coordinates  of  a 
fixed  point  into  the  eye  or  camera  coordinates,  is  given  by 

r  L  L  L  1 


ly  h 
TUy  m. 


(C.4) 


where  /x»  ^ind  L  are  the  components  of  the  unit  vector  /  of  the  Xc  axis 
along  the  world  and  2^,  axes,  respectively.  Similar  remarks  apply  to 

m  and  n. 

The  transformation  from  the  world  to  eye  coordinates  consists  of  two 
steps:  translation  and  rotation.  Under  the  homogeneous  coordinates[9,  10], 
the  associated  matrices  are: 


MT(Er,Ey,E^)  = 


Mh  = 


'  1 
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0 

-E, 
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-Ey 
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0 
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1 . 

(C.5) 


(C.6) 


is  not  necessarily  the  same  as  the  “up”  direction  of  the  world.  The  only  requirement 
for  u  is  that  u  lies  in  the  half  plane  determined  by  the  Zc  axis  and  the  postiive  yc  axis. 
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Concatenation  of  the  two  matrices,  i.e.  prcmultiplying  Mr  with  A/r, 


yields 


Mti,2e  — 


L 


•v 

m. 


ir 
nix 

Tlx  riy 
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n, 
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— m  •  E 
-n-E 
1 


(C.7) 


C.2.2  Scaling  Compensation 


In  order  to  avoid  the  nonuniform  scaling  in  the  horizontal  and  vertical  di¬ 
rections,  the  following  scaling  transformation  is  performed  after  the  world  to 
eye  transformation; 

0 
0 
0 


Af^co/e  — 
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0  0 
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0 
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1 
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0 

1 


(C.8) 


where 


{ 


Sx 

Sx 


=  height  I  width]  Sy  =  I 


=  1; 


Sy  =  height!  width 


if  width  >  height 
if  width  <=  height 


width  and  height  are  the  sizes  of  an  image. 


C.2.3  Perspective  Transformation 

In  order  to  achieve  the  3-D  effects  on  a  2-D  graphical  output  device,  the 
next  step  is  to  perform  the  perspective  transformation  in  the  eye  coordinate 
system.  The  3D  viewing  frustum  is  determined  by  the  field  of  viewing  angle, 
the  hither  and  yon  clipping  plane(See  Figure  C.2  -  a).  In  Dore,  the  camera 
is  located  at  the  origin  and  looks  towards  the  negative  direction  of  the  z- 
axis  of  the  camera  coordinate  system.  Thus,  the  hither  and  yon  planes  must 
be  specified  by  the  negative  floating  numbers  h  and  y,  respectively(|/ij  < 
|y|).  In  order  to  facilitate  the  clipping  process,  the  viewing  frustum  is  also 
transformed  ino  the  canonical  viewing  volume^].  This  canonical  viewing 
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volume  extends  evenly  2  units  of  distance  in  the  x  and  y  directions,  and 
extends  in  the  negative  z  direction  1  unit  of  distance.  See  Figure  C.2  -  b. 

The  transformation  which  maps  the  hither  and  yon  clipping  planes  into 
the  planes  z  =  0  and  z  =  —I  in  addition  to  the  perspective  projection  is 
given  by 


Mperap  — 


1 


0 

0 


0 

1 

Un  ^ 
0 
0 


0 

0 

1 

1-Vy 

-1 


0 

0 

-h 

l-h/y 

0 


(C.9) 


It  should  be  pointed  out  that  this  transformation  is  nonlinear:  a  line 
will  not,  in  general,  be  mapped  into  a  line.  A  line-of-sight(LOS)  originating 
form  the  eye  point  will,  however,  be  mapped  into  a  line  patrallel  to  the  z  axis. 
This  observation  is  important.  It  plays  an  key  role  in  the  inverse  process  of 
determining  the  LOS  given  the  screen  coordinates. 


C.2,4  Screen  Transformation 


After  the  perspective  projection  and  clipping,  the  frontmost  in  the  canonical 
volume  is  mapped  onto  the  physical  2D  graphical  output  device.  Let  us 
consider  the  case  where  the  2D  graphical  output  device  is  an  X  window. 
According  to  the  convention  in  X,  the  upper  left  hand  corner  of  the  window 
has  the  coordinates  (0,0).  The  positive  x,  direction  is  from  left  to  right, 
while  the  positive  direction  for  y,  is  vertically  downward.  See  Figure  C.3. 

Consider  the  rectangular  output  area  of  width  W  and  height  H  with  its 
centroid  located  at  (xc,yc)-  The  transformation  which  maps  the  normalized 
2x2  screen  to  the  above  physical  graphical  output  device  is  given  by 


A/. 


W/2 
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0  0  Xc  ' 

-H/2  0  Vc 

0  1  0 

0  0  1 


(C.IO) 


APPENDIX  a  GEOMETRICAL  TRANSFORMATION 


field  of  view(a) 


(a)  Viewing  frustum 


(b)  Canonical  viewing  volume 


Figure  C.2:  Perspective  transformation 
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Figure  C.3:  Screen  transformation 

C.2.5  Concatenation  of  Transformations 

The  overall  world  to  screen  transformation  is  the  concatenation  of  above 
series  of  transformations: 

A'/u;2s  ~  MgcreenMpcrspMgcaigMxi;2e  (^*11) 


Carrying  out  the  matrix  multiplications  yields: 

aly  —  XcTiy  al^  —  XcTiz  — a(/  •  E)  +  Xc(n  •  E) 
brUy-ycTiy  bm^-ycTi^  -6(m  •  E)  +  yc(n  •  E) 
cTiy  cTiz  — c[(n  •  E)  4- /i] 

—My  —riz  n  •  E 

(C.12) 

where 


2  tan  ^ 

HSy 

2t3Ji  f 
1 

1  -  h/y 


(C.13) 

(C.14) 

(C.15) 
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C.3  Screen  to  World  Transformations 


Given  the  screen  coordinates  it  is  insufficient  to  find  the  point  in  the 

world  coordinates  system,  as  the  depth  value  is  unknown.  However,  one 
can  find  the  LOS  of  the  corresponding  point  in  the  world  coordinate  system. 
As  remarked  in  Section  C.2.3,  given  the  fixed  z,,  y,,  the  screen  coordinates 
will  yield  the  same  LOS  for  any  values  —  1  <  <  0.  With  the 

range  information,  one  can  determine  the  corresponding  point  in  the  world 
coordinate  system. 

The  inverse  mapping  from  the  screen  to  world  coordinate  is  given  by 


where 


$2uj  —  ^w2s 


Bcreen 


(C.16) 
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^00 

0  0  10 

0  0  0  1 

Carrying  out  matrix  multiplications  yields 

air  brur  fEx  clx  -I-  drrix  ~  n*  +  iEx 

aly  bruy  fEy  cly  +  dniy  —  riy  +  eEy 

dl^  bm^  fEz  c/z  +  dm,  —  n,  +  eE, 

0  0/  e 

where 


d  = 

0-'  = 

2  a 

- tan  ^ 

VVa,  2 

(C.18) 

b  = 

6-*  = 

2  ,  a 

(C.19) 

c  = 

— azc 

(C.20) 

d  = 

-iyc 

(C.21) 

e  = 

-\lh 

(C.22) 

/  = 

e(l- 

>ily) 

(C.23) 

As  a  check,  one  can  verify  that  the  following  holds: 

Mxu2aMg2w  ~  Mz2wMxu2»  ~  I 


(C.17) 


Appendix  D 
Manual  Pages 


The  manual  pages,  in  the  standard  UNIX  on-line  inan(l)  page  format,  are 
listed  here  for  reference.  These  man  pages  are  intended  to  be  a  quick  reference 
for  the  usage  of  the  command  line  options.  The  specification  of  the  file 
formats  are  omitted. 

If  you  have  set  your  environment  variable  MANP.ATH  appropriately,  you 
can  access  manual  pages  on-line  by  typing,  for  example, 

example^  man  hitert 
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DATACONTROL(l)  UNIX  Programmer’s  ManuaJ  DATACONTROL^  I ) 

NAME 


daiaCootrol  -  Data  G^ntrol  module 


SYNOPSIS 

dataControl  -imglnfo  imgInfoFiU  -seginfo  segInfoFile 

-to  siari-itme  -te  end-itme  -oimginfo  ouUimgJnfoFiU  -oeeginfo  ouUsegInfoFiU  -traj  ouUexacUiraj 
-spec  out- spec 

DESCRIPTION 

daiaConirol  takes  the  description  files  for  the  world  view  image  database  amd  the  segmented  image 
database,  respectively,  as  inputs.  It  outputs  the  selected  segments  of  the  description  files,  exact 
trajectory  data  file  and  the  spec  file  containing  the  information  for  the  starting  and  terminating 
point. 


OPTIONS 

Required  argument.  imgInfoFile  is  the  name  of  the  description  file  for 
the  world-view  image  database  of  the  whole  time  history, 

Required  argument.  segInfoFile  ’is  the  name  of  the  description  file  for  the 
segmented  image  database  of  the  whole  time  history. 

Required  argument,  siari-iime  specifies  the  time  at  which  the  tracking 
system  should  start  to  run. 

-te  end-time  Required  argument,  end-time  specifies  the  time  at  which  the  tracking  system  should 
terminate.  By  specifying  start-time  and  end-itme,  one  can  ask  system  to  run  over 
the  selected  segment  of  the  trajectory  of  interest  instead  of  the  whole  time  history. 

-oimginfo  oui-imgInfoFUe  Required  argument.  oui-imgInfoFUe  specifies  the  name  of  descrip¬ 
tion  file  for  the  selected  segment  of  the  world-view  image  database. 

-oseginfo  out- segInfoFile  Required  argument,  out- segInfoFile  specifies  the  name  of  description 

file  for  the  selected  segment  of  the  segmented  image  database. 

-traj  out- exact- traj  Required  argument,  out- exact- traj  specifies  the  name  of  file  containing  se¬ 

lected  segment  of  exact  trajectory  data. 

-spec  out-spec  Required  argument,  out-spec  specifies  the  name  of  file  containing  information 
corresponding  to  the  starting  and  terminating  points. 


-imginfo  imgInfoFile 

-seginfo  segInfoFile 
-to  start-time 


SEE  ALSO 

hitert(l) 

AUTHORS 

Jun  Lu,  Dominick  Andrisani  II.  Purdue  University  School  of  Aeronautics  and  Astronautics 
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NAME 

w.c«mei&  -  Retur'>'i  the  sequence  of  user  specified  input  files. 

SYNOPSIS 

w.camera  (-dir  dirtciory]  [-prefix  [-num_width  num-widtK[  [-suffix  snffi:^  -inSpec  inSpec  - 

outSpec  ouiSptc  [-img  [-uc  <1  or  0>]  [-help] 

DESCRIPTION 

w.camera  returns  an  desired  input  file  according  to  the  user  specified  directory,  prefix,  sequence 
number,  suffix.  The  sequence  numbers  are  extracted  from  the  inSpcc  file.  The  tnSpec  file  consists 
of  the  sequence  numbers,  data  records  from  the  description  file  for  the  world-view  image  database 
and  data  records  from  the  description  file  for  the  segmented  image  database.  The  outSpec  consists 
of  the  sequence  numbers,  image  file  names,  data  records  from  the  description  file  for  the  world-view 
image  database  and  data  records  from  the  description  file  for  the  segmented  image  database.  If  the 
input  filename  has  it  is  assumed  to  be  in  the  compressed  format.  The  compressed  input  files 
will  be  uncompressed  to  produce  the  output  image  file  if  the  ”-uc  1”  option  is  specified,  (this  is  also 
the  default).  However,  if  "-uc  0”  is  specified  and  if  the  input  files  have  the  tag  ".Z”,  the  compressed 
image  files  will  be  copied  to  produce  the  output  image  files.  In  this  case,  the  output  image  files  are 
tagged  with  ”.2”  to  indicate  that  they  are  compressed  files. 

No  assumption  has  been  made  that  the  prefix,  sequence  and  suffix  are  separated  by  the  character 
period  If  they  are  indeed  separated  by  such  a  character,  they  should  be  explicitly  specified 
either  in  the  prefix  or  suffix  part. 

OPTIONS 

[-dir  directory]  Optional  argument.  This  option  specifies  the  directory  from  which  the  input  file 
is  to  be  picked  up.  It  is  an  optional  argument.  Default:  the  current  directory. 

[-prefix  prefix]  Optional  argument.  This  option  specifies  the  part  in  the  input  file  name  that 
precedes  the  sequence  number.  It  is  an  optional  argument.  Default:  null. 

[-num.width  num-widih]  Optional  argument.  The  width  that  the  numeric  sequence  takes  may 

be  specified  through  this  optional  argument.  If  the  num-wtdik  is 
greater  them  the  number  of  the  digits  the  sequence-number  (as  specified 
in  -num  )  has,  the  sequence-number  will  be  prepended  with  zero  s(O’s) 
so  that  the  width  of  the  sequence  string  will  be  the  same  as  num-widih. 
Default:  the  sequence  string  is  as  long  as  the  the  number  of  digits  that 
the  sequence  number  has. 

[-suffix  ssj^x]  Optional  argument.  The  option  specifies  the  part  of  the  filename  that  follows  the 
sequence  string.  If  the  last  two  characters  of  the  suffix  string  are  ”.2”,  then  the 
input  file  will  be  assumed  to  in  compressed  format,  and  uncompressed  data  file 
will  be  produced  using  uncompress f  J).  Default:  null 

-inSpec  tnSpec  Required  argument.  tnSpec 

specifies  the  name  of  a  input  specification  file.  This  file  is  not  actual  output 
"data  or  image”  file;  rather,  it  contains  data  records  of  the  form:  sequence- 
number  followed  by  a  data  record  from  the  description  file  for  the  world-view 
image  database  and  a  data  record  from  the  description  file  for  the  segmented 
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image  database,  which  are  separated  by  the  white  space  character8(8pace,  tab, 
newline). 

-outSpec  oniSftc  Required  argument.  ouiSptc 

specifies  the  name  of  a  output  specification  file.  This  file  is  not  actual  output 
"data  or  image”  file;  rather,  it  contains  data  records  of  the  form:  sequence- 
number,  followed  by  the  file  name  for  the  corresponding  output  image,  followed 
by  a  data  record  from  the  description  file  for  the  world-view  image  database 
and  a  data  record  from  the  description  file  for  the  segmented  image  database, 
which  are  separated  by  the  white  space  character8(8pace,  tab,  newline). 

[.img  imgfile]  Optional  argument,  tmgfile  specifies  the  name  of  the  output  image  files.  If  this 
option  is  not  specified,  the  default  path  name  for  imgfile  is  /tmp/w.cari.$USER, 
where  SUSER  is  expanded  to  the  login  name  of  the  user.  If  more  than  one  image 
sequences  aire  specified  in  the  inSpec,  the  output  image  files  will  have  the  names 
imgfile[.Z],  tmgfiUl[.Z],  tmgfile2[.Z],  ... 


EXAMPLES 


%  w.camera  -dir  SHITERT.HOME/data/images/scenel  \ 
-prefix  sl.img -num.width  4  -suffix  Z  \ 

-inSpec  inSpec  -outSpec  outSpec 


SEE  ALSO 

hitcrt(l),  V8eqdir(l),  t..camera(l) 

AUTHORS 

Jun  Lu,  Dominick  Andrisani  II,  Purdue  University  School  of  Aeronautics  and  Astronautics 
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NAME 


t.camefa  -  Batch-mode  tracking  camera  module  in  HiTert  System 

SYNOPSIS 

t.camera  -world  world-sptc  -noise  noise  -o  ouiSpec  [-help] 

DESCRIPTION 

Lcamera  ,  conceptually,  takes  world  view  image  and  tracking  commands( where  should  camera  look 
at  ?)  and  outputs  the  acquired  image  to  the  image  processor  for  segmentation  and  to  the  instrumen¬ 
tation  module  for  displaying  purpose.  However,  since  in  batch- mode  imageries  are  presegmented, 
tracking  camera  image  to  the  image  processor  is  not  really  needed.  However,  the  image  processor 
need  to  know  the  tracking  camera  command8( where  is  camera  looking  at  ?)  in  order  to  compare  with 
the  presegmented  image  to  output  the  appropriate  overlapping  area  of  the  images.  Also  since  the 
the  world  view  image  is  available  to  the  instrumentation  module,  the  instrumentation  module  may 
display  appropriate  subimage  according  to  the  tracking  camera  commands.  Therefore  no  tracking 
camera  image  is  really  needed.  For  implementation  efficiency,  t.camera  does  not  output  images.  It 
merely  make  its  its  state  information  available  to  other  down-stream  modules. 


OPTIONS 

-world  world-spec  The  world-spec  contains  the  information  about  the  time  and  the  filename  cor¬ 
responding  world-view  image,  as  well  as  the  data  records  from  the  description 
file  for  the  world-view  image  database  and  the  data  records  from  the  descrip¬ 
tion  file  for  the  segmented  image  database. 


-noise  noise  Required  argument.  It  specifies  the  name  of  the  file  containing  three  floating  num¬ 
bers  representing  white  noise  intensities  for  x,  y  and  z  directions  respectively.  The 
exact  target  position  as  obtained  from  world-spec  are  perturbed  with  Gaussian  ran¬ 
dom  values  with  their  standard  deviations  determined  by  noise  intensities,  respec¬ 
tively.  The  perturbed  values  are  used  to  simulate  where  the  actual  tracking  camera 
is  looking  at.  By  changing  the  input  noise  intensities,  one  may  mimic  the  tracking 
cameras  with  different  tracking  accuracies. 


-o  ouiSpec  Required  argument.  It  specifies  the  name  of  the  output  spec  file. 


[-help]  Lcamera  will  print  out  brief  help  message  if  this  option  is  specified.  Note  this  option  is 
designed  to  give  a  quick  help  to  the  user  via  unix  command  line  option.  It  does  not  work 
with  caniaia(l). 


SEE  ALSO 

hitert(l),  w_camera(l),  xhitert(l) 

AUTHORS 

Jun  Lu,  Dominick  Andrisani  II,  Purdue  University  School  of  Aeronautics  and  Astronautics 
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NAME 

ipc  -  Image  Proceaior. 

SYNOPSIS 

ipc  -imginfo  tmgInfoFtU  -seginfo  stglnfoFiU  -inSpcc  xnSpec 

[-dir  dirrctory]  [-prefix  prtfiz]  [-num.width  num-wtdih]  [-suffix  3uffiz\  -meaa  mcfljarement  -outSpec 
ouiSpcc  [-img  tmage-fiU]  [-uc  <1  or  0>)  [-help] 

DESCRIPTION 

ipc  computes  the  target  centroid  position  according  to  segmentation  results  and  range  information 
that  are  contained  ‘in  tmgInfoFtU  and  segInfoFiU.  It  also  returns  an  desired  output  file  according 
to  the  user  specified  directory,  prefix,  sequence  number,  suffix.  The  sequence  numbers  arc  extracted 
from  the  tnSptc  file. 

If  s%ffii  is  ”.2”,  it  is  assumed  that  the  corresponding  input  file  is  in  the  compressed  format.  The 
corresponding  output  image  files  will  be  uncompressed  or  remain  compressed  depending  on  the 
option  specified  for  ’’-uc*’.  If  the  output  image  file  remain  compressed,  the  output  image  files  are 
tagged  with  ”.2”  to  indicate  that  they  are  compressed  files. 

No  assumption  has  been  made  that  the  prefix,  sequence  and  suffix  are  separated  by  the  character 
period  ”  If  they  are  indeed  separated  by  such  a  character,  they  should  be  explicitly  specifigj^ 
either  in  the  prefix  or  suffix  part, 

OPTIONS 

-imginfo  tmgInfoFtU  Required  argument.  This  option  specifies  the  description  file  for  the  world¬ 
view  image  database. 

-seginfo  scgInfoFtU  Required  argument.  This  option  specifies  the  description  file  for  the  seg¬ 
mented  image  database. 

-inSpec  tnSpec  Required  argument.  This  option  specifies  an  input  file  to  the  program.  This 
input  spec  file  comes  from  the  output  spec  file  of  the  tracking  camera. 

[-dir  directory]  Optional  argument.  This  option  specifies  the  directory  from  which  the  input  file 
is  to  be  picked  up.  It  is  an  optional  argument.  Default:  the  current  directory. 

[-prefix  pre/ix]  Optional  argument.  This  option  specifies  the  part  in  the  input  file  name  that 
precedes  the  sequence  number.  It  is  an  optional  argument.  Default:  null. 

[-num.width  num-widih]  Optional  argument.  The  width  that  the  numeric  sequence  takes  may 

be  specified  through  this  optional  argument.  If  the  num-wtdih  is 
greater  than  the  number  of  the  digits  the  sequence-number  (as  specified 
in  -num  )  has,  the  sequence-number  will  be  prepended  with  zero*8(0*8) 
so  that  the  width  of  the  sequence  string  will  be  the  same  as  num-widik. 
Default:  the  sequence  string  is  as  long  as  the  the  number  of  digits  that 
the  sequence  number  has. 

[-suffix  suffix]  Optional  argument.  The  option  specifies  the  part  of  the  filename  that  follows  the 
sequence  string.  If  the  last  two  characters  of  the  suffix  string  are  ”.2”,  then  the 
input  file  will  be  assumed  to  in  compressed  format,  and  uncompressed  data  file 
will  be  produced  using  uncompress(l).  Default:  null 
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•inSp^  inSpec  Required  argument.  inSpec 

specifies  the  name  of  a  input  specification  hie.  The  tn5pec  file  has  possibly  several 
data  records,  with  each  data  record  consisting  of  a  sequence  number,  a  filename 
specifying  the  world-view  image,  the  point(center  of  interest  -  COI)  that  the 
tracking  camera  is  looking  at,  the  screen  coordinates  of  COI  in  the  world- view 
image,  a  data  record  from  the  description  file  for  the  world-view  image  database 
and  a  data  record  from  the  description  file  for  the  segmented  image  database,  all 
of  which  are  separated  by  the  white  space  characters(space,  tab,  newline). 

-outSpec  outSpec  Required  argument.  ouiSpec 

specifies  the  name  of  a  output  specification  file.  The  outSpec  has  the  same 
number  of  data  records  as  inSpec  hie.  But  each  data  record  in  outSpec  is 
slightly  different  from  that  in  inSpec.  Each  data  record  in  ouiSpec  consists 
of  the  sequence  numbers,  the  world-view  image  hlenamc,  the  hlename  for  the 
segmented  image,  the  point(center  of  interest  -  COI)  that  the  tracking  camera 
is  looking  at,  the  screen  coordinates  of  COI  in  the  world-view  image,  the  data 
record  from  the  description  hie  for  the  world-view  image  database  and  data 
records  from  the  description  hie  for  the  segmented  image  database,  all  which 
are  separated  by  the  white  space  character8(space,  tab,  newline). 

[-img  imgfile]  Optional  argument,  imgfile  specihes  the  name  of  the  output  image  hies.  If  this 
option  is  not  specihed,  the  default  path  name  for  imgfile  is  /tmp/ipImg.$USER, 
where  $USER  is  expanded  to  the  login  name  of  the  user.  If  more  than  one  image 
sequences  are  specihed  in  the  inSpec,  the  output  image  hies  will  have  the  naiiW 
imgfilelZ],  imgfilei[.Z],  tmgfile2lZ],  ... 

[-UC  <1  or  0>]  Optional  argument.  This  boolean  flag  specihes  whether  or  not  to  uncompress 
the  input  hle(s)  specihed.  If  suffix  is  .Z’' ,  it  is  assumed  that  the  corresponding 
input  hie  is  in  the  compressed  format.  It  will  be  uncompressed  to  produce  the 
output  image  hie  if  the  '^-uc  P  option  is  specihed.  (this  is  also  the  default). 
However,  if  ”-uc  0”  is  specihed  and  if  the  input  hies  have  the  tag  ”.Z”,  the 
compressed  image  hies  will  be  copied  to  produce  the  output  image  hies.  In 
this  case,  the  output  image  hies  are  tagged  with  ’".Z”  to  indicate  that  they  are 
compressed  hies.  This  option  has  no  effect  if  the  input  hie  has  no  tag  ".Z”. 

EXAMPLES 


%  ipc  -imginfo  ../dataControl/imginfo  \ 

-seglnfo  ../dataControI/seginfo -inSpec  inSpec  \ 
-dir  SHITERT-HOME/data/images/secnel  jeg  \ 
-prefix  sLseg  -num.width  4  -suffix  .Z  \ 

-meas  measurement  -outSpec  outSpec 


SEE  ALSO 

hitert(l),  vseqdir(l),  w.camera(l) 

AUTHORS 

Jun  Lu,  Dominick  Andrisani  II,  Purdue  University  School  of  Aeronautics  and  Astronautics 
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NAME 


track  -  An  alpha-bet^-gamma  tracker 

SYNOPSIS 

track  -ip  ip.daia  -ic  ic.file  -o  ouUfiUnamt 

DESCRIPTION 

track  takes  noise-contaminated  measurement  data  as  input  and  gives  the  optimal  estimation  of  the 
state  using  Kalman  filter  theory. 

OPTIONS 

-ip  ip^daia  Required  argument,  ip.daia  is  the  name  of  the  file  which  contains  the  measurement 
data  as  obtained  from  the  image  segmentation.  The  measurement  data  file  consists 
of  the  data  records  of  the  form: 

t  x-measure  y-measure  2-measure 


[-ic  ic^file]  Optional  argument,  is  the  name  of  the  file  which  contains  initial  conditions  Br 

the  tracker.  It  has  the  following  data  items,  all  of  which  are  separated  by  the  white 
space  characters. 

-ic  ic-file  Optional  argument.  The  tc-fiU  contains  the  initial  conditions  for  the  states  of  the 
tracker.  It  consists  of  the  following  data: 

to 

where  x,  z,  z,  y,  y,  y,  i,  z  and  i  are  the  initial  conditions  at  the  starting  time  to.  If 
this  option  is  not  specified,  track  will  set  z,  z,  z,  y,  y,  y  i,  i  and  f  all  to  zeros  as  the 
default  values  for  the  initial  conditions. 


-o  out.filename 


Required  argument.  ouLfilename  is  the  name  of  the  file  which  contains  optimal 
state  estimations.  It  consists  of  the  data  records  of  the  form: 


i 


y  y  y  ^ 


where  x  ,  x,  i,  y,  y,  y  z,  z,  z  are  the  estimated  states  at  the  time  t. 


SEE  ALSO 

hitert(l),  predict(l),  xhitert(l) 

AUTHORS 

Jun  Lu,  Dominick  Andrisani  II,  Purdue  University  School  of  Aeronautics  and  Astronautics 
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NAME 

predict  -  The  alpha-beta-gamma  tracker 

SYNOPSIS 

predict  -i  in-filename  [-tp  sec]  -o  ouUfilename 

DESCRIPTION 

predict  performs  sec  ahead  prediction  based  on  the  state  estimation  from  the  alpha-beta-gamma 

tracker. 

OPTIONS 

-i  in-filename  Required  argument,  in-filename  is  the  name  of  the  file  which  contains  the  state 
estimation  of  the  alpha-beta-gamma  tracker,  the  "best”  estimation  about  the  tar¬ 
get’s  position,  velocity  and  acceleration.  It  consists  of  the  data  records  of  the 
form: 

txxxyyyzzz 


where  x,  x  and  x  are  the  position,  speed  and  acceleration  of  the  target  at  time  <o^ 
has  the  unit  of  seconds;  whereas  x,  x  and  x  have  units  of  meters,  meters /seconds^ 
and  meter s / {secondsy^ ,  respectively.  Similar  remarks  apply  to  y,  y,  y,  I,  i  and  2, 
respectively.  These  data  are  separated  by  one  or  more  mixed  white  space  charac¬ 
ters. 


[-tp  see] 


Optional  argument,  sec  is  the  expected  time  of  flight  of  a  projectile  intercepting  the 
target. 


o  out-filename 


Required  argument,  out-filename  is  the  name  of  the  file  which  contains  predicted 
target  position.  It  consists  of  the  data  records  of  the  form: 

t  t,  x(tf\t)  y(ti\t) 


where  t  is  the  current  time,  tj  the  future  time(t/  =  t  y(tf\t)  and 

z{tf\t)  the  predicted  target  position  coordinates  at  tj  based  on  the  current  state 
estimates  at  t. 


SEE  ALSO 

hitert(l),  track(l) 

AUTHORS 

Jun  Lu,  Dominick  Andrisani  II,  Purdue  University  School  of  Aeronautics  and  Astronautics 
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NAME 

errAnaly  -  Performs  error  analysis  for  the  tracking  system. 

SYNOPSIS 

errAnaly  -pred  predfile  -exact  exacifiU 

[-showErr  <1  or  -outSpec  outSpec  [-outErr  ouiEn]  [-help] 

DESCRIPTION 

errAnaly  computes  error  metrics  for  the  tracking  system,  using  the  prediction  data  and  exact  data. 
OPTIONS 

-pred  predfile  Required  argument.  It  specifies  the  file  that  contains  the  prediction  data  from  the 
predictor. 

-exact  exacifile  Required  argument.  It  specifies  the  file  that  contains  the  exact  data  for  compar¬ 
ison. 

-showDart  show  Dart  Optional  argument.  If  showDart  is  0,  errAnaly  will  compute  the  inl^ 

tial  component  errors  and  write  these  errors  to  a  data  file(see  option 
outErr  outEn^).  If  showDart  is  1,  errAnaly  will  compute  the  dartborad 
errors  and  write  these  errors  to  a  data  file(see  option  ”-outErr  ouiEn^). 
These  error  data  are  intended  main  for  graphical  displaying  purpose.  The 
statistics  are  are  always  computed  based  on  the  inertial  component  errors. 
Default:  1 

-tbf  ibf  Optional  argument,  ibf  is  track- before-fire  time  in  seconds.  Default:  0 

-tburst  tburst  Optional  argument,  iburst  is  the  burst  interval  in  seconds.  Default:  from  starting 
point  to  the  terminating  point. 

Example:  -showDart  0 

-outSpec  ouiSpec  Required  argument.  It  specifies  the  name  of  the  file  that  contains  the  output 
c  file,  which  contains  statistics  of  the  errors  and  the  filename  of  the  actual 
<  error  data  file. 

-outErr  ouiErr  Optional  argument.  outErr  specifies  the  name  of  the  file  which  contains  the 
actual  error  data.  Default;  /tmp/errAnaly.login 

SEE  ALSO 

hitert(l),  predict(l),  xhitert(l) 

AUTHORS 

Jun  Lu,  Dominick  Andrisani  II,  Purdue  University  School  of  Aeronautics  and  Astronautics 
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NAME 


xhitert  -  Instnimentation/display  module  for  the  HiTert  System 


SYNOPSIS 

xhitert  -world  trorW -camera  camerastaie  -ip  ip.ouifilt  -pred  prtdictor.data  -exact  ezacLtrajcctory 
[-display  display] 


DESCTIPTION 

xhitert  is  a  program  which  runs  under  X  window  system.  It  graphically  displays  the  run-time  status 
of  the  HiTert  system.  Graphically,  xhitert  has  the  following  components  in  its  top  level  window: 

an  image  of  a  world  view. 

an  image  as  seen  by  the  tracking  camera. 

an  image  segmented  by  the  image  processor. 

a  dart-board,  which  displays  the  prediction  errors. 

exact  trajectory  and  the  predicted  trajectory. 

tabulated  numerical  results  of  the  error  analysis. 

Functionally,  xhitert  take  the  inputs  from  the  "camera’*,  which  provides  the  world  view  image  and  the 
state  of  the  tracking  camera  so  that  the  xhitert  can  find,  from  the  world  view  image,  the  subimage 
corresponding  to  the  tracking  camera.  It  also  takes  as  its  input  the  segmented  from  the  image 
processor  and  displays  all  the  input  images.  Besides,  xhitert  takes  as  its  inputs  the  tracker/predictor 
results,  performing  error  analysis,  mimicking  dart-board  and  display  exawrt  and  predicted  trajectories. 

This  version  is  designed  to  work  in  the  batch-mode  of  the  HiTert  system. 


OPTIONS 

Required  argument.  It  specifies  the  ASCII  file  which  contains  the  image-sequence- 
number  followed  by  the  world-view-image  filename,  image- sequence-number  is 
used  to  carry  the  time  information  that  the  image  corresponds  to.  time  and 
filename  are  separated  by  white  space  character(s). 

Required  argument.  It  specifies  the  ASCII  file  which  contains  the  tracking  camera 
state. 

Required  argument.  It  specifies  the  ASCII  file  which  contains  the  measurement 
as  segmented  by  the  image  processor. 

-pred  predicteiLresuHs  Required  argument.  It  specifies  the  file  which  contain  the  prediction  results. 

-exact  exact  Required  argument.  It  specifies  the  file  which  contains  the  exact  trajectory  data. 

-display  host:  diplay  .screen  Optional  argument,  which  specifies  where  to  display  zhitert's  graphical 
output. 

-demo  <0  or  1>  Optional  argument.  This  boolean  flag  specifies  whether  or  not  to  display  the 
tracking  results  in  a  pseudo  real-time  mode.  If  demo  is  false,  i.e.,  0,  all  the 
tracking  results  will  be  blasted  to  the  screen  almost  at  the  same  time;  if  demo  is 
true,  however,  zhiiert  will  be  in  the  pseudo  real-time  mode,  displaying  the  tracking 
results  one  at  a  time. 


-world  world 


-camera  camera 


-ip  ip 
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XHITERr(l) 


I'NIX  Programmer’s  Manual 


XHITEFn’(l) 


-help 


Optional  airgument.  When  specified,  thxUrt  will  print  out  biref  help  message. 


SEE  ALSO 
X(l) 
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